Hi Max thanks for the reply. Okay this is what I can tell you about things: I have an "EAR Project" called "EAREclipseManager", this has 2 artifacts added to it. These are 1 x "J2EE Utility project" called "TheLibrary" and 1 x "EJB Project" called "TheEJB". If I do a project properties on the "EAR Project" under "J2EE Dependancies" I has a tick for both of the other two projects set. The EAR Project has the Project Facet "EAR" set to "5.0", Project References also has a tick for both of the other two projects set, Seam Support is disabled (no tick in box), Targetted Runtime is : JBoss AS 4.2. Is is the encapsulating EAR project I am trying to publish. I don't think I need to do anything special with the project settings of the 2 contributing projects do I ? The deployment appears to be attempted in: /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/ | /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheLibrary.jar | /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/META-INF/ | /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/ | /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/META-INF/ | /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/my/ | /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/my/foobar/ | /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/my/foobar/eclipse/ | /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/my/foobar/eclipse/ejb/ | /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/my/foobar/eclipse/ejb/manager/ | /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/my/foobar/eclipse/ejb/manager/test/ | Hmm... when I run a "clean" function from the server tooling with the WTP provider driver I get an error: [jar] Building jar: $HOME/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp2/EAREclipseManager.ear | [move] Moving 1 file to /opt/jboss-4.2.1.GA/server/default/deploy | | BUILD FAILED | /opt/eclipse/plugins/org.eclipse.jst.server.generic.jboss_1.5.105.v200709061325/buildfiles/jboss323.xml:33: Failed to copy $HOME/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp2/EAREclipseManager.ear to /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear due to /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear (Is a directory) Is it possible to confirm 2 things: * Which method of deployment does JBossTool-AS use, does it create an exploded EAR ? When it created that exploded EAR does it create a directory with a ".ear" extension in the deploy directory ? Does an exploded EAR need to have a .ear extension so its treated correctly by the correct deployer ? * Does it matter that my workspace and my JBoss runtime location are on different file system (different drives), since its not possible to rename files between my workspace and the JBoss runtime location. The IDE must perform a file copy. * When the files are copied are they copied atomically, i.e. each file is copied into tmp/filename.tmp first, then its last modified time is fixed to whatever it needs to be, then its renamed (i.e. moved) to the deploy/whatever/filename.foo. There are other such things which should take place when updating a working runtime but maybe more on that once I have the basic thing ticking along. Okay I have manually cleaned the JBoss deploy directory of my project and let the WTP JBoss driver do its stuff and it create an .ear file in the correct directory and when JBoss starts it finds both application.xml and my TheEJB.jar implementation. I cleaned things again and tried with the JBossTool-AS driver and it created a directory with .ear extension, the tree is just like I put in the CODE block above, with AREclipseManager.ear/TheLibrary.jar being the only file and the application.xml and the .class files are all missing. So the problem for me appears to be with the JBossTool-AS driver (which is my preferred choice). Would there be any call to allow JBoss to take a command line property to configure a 2nd and alternative deployment directory ? The purpose of this would be to allow for a Tomcat like situation where the workspace area could be used for the deployment, when you just alter the driver to contribute the property to the launch configuration when it sets things up. Okay it would not be 100% compatible with tomcat since the work, tmp, log, etc.. directories would also need to be picked up based on the alternative path too. Just a thought, since it would seem difficult for "clean" to mean clean if the deploy directory was not empty to start with. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092549#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...