I upgraded WTP plugin to 3.4 manually, (this is JBoss Dev Studio 5.0.1), and the problem remains.
Here's a more complete description of what I'm talking about:
Some-EJB => deploys as a .jar depends on utility project
utility => doesn't deploy
utility-web => doesn't deploy
WebApp1 => deploy as .war depends on utility and utility-web projects
WebApp2 => deploy as .war depends on utility and utility-web projects
Obviously we aren't using a .ear for historical reasons.
Full publish Some-EJB to JBoss on localhost => ok has utility.jar
Full publish WebApp1 to JBoss on localhost => ok has utility and utility-web jars in WEB-INF/lib
Full publish WebApp2 to JBoss on localhost => ok has utility and utility-web jars in WEB-INF/lib, but utility and and utility-web are deleted from WebApp1/WEB-INF/lib
Question: does anyone from the dev team even read this stuff?
I have just tried to reproduce this and am unable to. I will be adding my attempts as a unit test to verify that programatically it also fails to reproduce, and also to ensure that if a regression such as this ever comes back, it will be caught by unit test.
However, as I said, I am unable to reproduce it. The code so far is heavily unit tested, and two independent deployments (web1 and web2) should *never* reach inside each other's deployment folders at all. This is extremely unlikely and basically would violate the entire structure of the codebase to be able to do it.
If the items were inside an ear together, it would be *slightly* more likely to happen, but even then, our unit tests are fairly extensive and becoming more-so every day.
I would be glad to post up a zip file of the respective projects in case you would like to use them to reproduce. But I've been trying all morning and everything seems to be working as intended.
I have added the test over at: https://source.jboss.org/browse/~raw,r=42846/JBossTools/trunk/as/tests/org.jboss.tools.as.test.core/src/org/jboss/tools/as/test/core/parametized/server/publishing/defect/PublishWeb2DeletesWeb1LibsTest.java
THe test imports the 5 projects with the structure you mentioned above. IT adds them to the server one by one, executing a full publish each time. It then verifies the new module publishes properly with its libs, and also, that the previouspublished modules libs still exist.
The unit test fails to replicate your issue.