"max.andersen(a)jboss.com" wrote : I just can't reproduce this error and thus I'm asking you if | | a) this occurs with other deployers too | | b) did you see leftover artifacts when using our jboss deployer | | If a and b then this is most likely limited only to possible issues in jstpublisher, if a and not b or not and b then it is some issue specific to our tooling. a) I can't comment on 'a' since I don't have any other deployers setup, just Tomcat and JBoss. As I understand the limitations with Java/JVM and Unix system semantics I'm happy to claim that all users of WST PublishUtil are affected while the "File tempDir" member has a hardwired value. It's important to phrase the question 'b' correctly "this occurs with other deployers that deploy to runtimes outside of the workspace filesystem that also use PublishUtil class provided by WST in WTP to place the files into the deployment directory". Maybe you can pick a deployer and container you'd like to me to spare a minute to test it with ? b) Yes I do. Here are the left over files (from $HOME/workspace/.metadata/.plugins/org.eclipse.wst.server.core/ to my example EAREclipseManager.ear project from deploying a moment ago: tmp40855.xml tmp40856.MF tmp40857.xml tmp40858.class tmp40859.class tmp40860.class tmp40861.class The modification to the JBoss runtime deploy directory has all the directories created that I'd expect to see for the project, but the 7 missing files are the MANIFEST.MF, the ejb-jar.xml, the application.xml and 4 x Implementation .class files. Examining the contents of those 7 tmpXXXXX.???? files clearly indicate they are those files, left over from failed renameTo() calls. I'd like to help you observe the issue, this would be best on a linux system (as that is what I use day-to-day). Please confirm your file system layout from 'df', the absolute location of your workspace, the absolute location of your project, the absolute location of your jboss runtime. I can then confirm if I believe your configuration should be able to observe the problem and provide steps. anonymous wrote : And we can't perform that change since it won't be ready in a WTP release in time; so we probably need to fork PublishUtil to make it work. There is always the option of listing the (cross filesystem boundary) as a known issue for the CR1 release. Since it is not that difficult to work around for a developer to ensure his runtime is on the same file system as his workspace. Open an API request ASAP and creating a backwards compatible implementation of the static PublishUtil and a new instancable delegate. But... I do think the lack of UI feedback over publish failure is a MUST FIX item for any major release. When the renameTo fails the user must know (no silent failures). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4095061#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...