Some developers just give up and use Ivy retrieve to dump the dependencies into the WEB-INF/lib directory; this will work, but is not a very elegant solution. To make this work, you are required to refresh the workspace after the Ivy resolve/retrieve completes, which pushes the dependencies into the web application; nasty.
This problem may have been answered in Eclipse 3.6 (Helios). I tested some of the 3.6 milestone releases, but was fooled into thinking that the IvyDE and WTP integration was broken; the J2EE module dependency option was no longer visible on the project properties. I was too busy to investigate (or look at other menu options!), I just assumed that it was just broken. To make a long story short, there is a new menu option called Deployment Assembly. The new option is a much simpler concept to comprehend; it is more flexible and actually seems to work consistently with Ivy. The most obvious change is the presentation; it gives a better picture of how the web application will be assembled. The old J2EE Module Dependency manager allowed you to choose components, but might have been more tailored for building an EAR file, rather than a WAR. Another issues is the inability to exclude any of the “source” folders. If you manage your unit test classes in a separate source folder, they would also be included in the application (WAR). Not necessarily a problem, but not very clean and could possibly hide unintended dependencies between the two source trees.
When using IvyDE, the first step is to add an Ivy classpath container. This will add Ivy dependencies to the classpath of your Eclipse project. If you have a WTP project, you will also need these dependencies copied to the WEB-INF/lib directory. This is easily accomplished by clicking the Add button under Deployment Assembly (under project properties). You can add other projects and external jars as well. Here is where it gets interesting, there appears to be two different options. If you have already added the Ivy classpath container to your build path, click the “Referenced Classpath Entries” option and select the ivy.xml file from your project. There might be a little display problem, as the “Deploy Path” for the classpath container does not appear correct, but it does put the libraries in the correct directory location.
The second option is to remove the Ivy classpath container from the build path, and re-add it under the new Deployment Assembly properties. This option displays properly and copies the dependencies to the WEB-INF/lib directory. I actually prefer this option, but there is a significant problem; there is no way to re-resolve the dependencies; it appears you need to delete the container and re-add it, if you change your ivy.xml file. Rather annoying!
I started writing this blog a couple of weeks ago and was under the impression that the new version was working perfectly. However, I’m currently back to where I started, with inconsistent, unexplainable behavior. Time to submit a question to the Ivy support list. Hopefully, I will have something to report back soon.
July 2nd, 2010 1:05 am
Opening a bug against wtp could help too.
We help form
The new assembly page so if that is behaving weird we can help track
Down the issue. Just needs some description on how to reproduce.
July 5th, 2010 11:50 pm
>> it appears you need to delete the container and re-add it, if you change your ivy.xml file. Rather annoying!
This may be a JDT bug, or a bug in the way WTP is dealing with JDT. I’d really need an easier use-case to investigate properly though 🙁
July 13th, 2010 7:29 am
Thanks for your blog entry, it helped me to find out where to add IvyDE-contributed class path entries to a WTP project in the first place.
I was unable to get it to work using ‘Referenced Projects CP Entries’ (it nevery copied any JARs), but got it to work using ‘Classpath Container’. As long as I didn’t change anything on the IvyDE container settings screen, it would let me add a new IvyDE container. The confs can then be edited manuall in .settings/org.eclipse.wst.common.component. Or just add these lines manuall to the settings file:
consumes
July 13th, 2010 7:30 am
Blog doesn’t like XML:
<dependent-module deploy-path=”/WEB-INF/lib”
handle=”module:/classpath/con/org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER/? ivyXmlPath=ivy.xml&confs=build,runtime”>
<dependency-type>consumes</dependency-type>
</dependent-module>
July 14th, 2010 5:15 am
When starting the server after adding new dependencies which it doesn’t find, try removing the app from the server, cleaning the server, re-adding the app. If that still doesn’t help, throw in a project close/open as well.
July 14th, 2010 8:59 am
I have the same problems in Galileo and Helios. When I add, remove or modify adependency in the ivy file, this dependency is not published/unpublished in Tomcat6 and sometimes any library gets published…
In Eclipse Galileo, I had a “trick” to get my dependencies published propertly. Maybe it’s not the best way to do it but at least it works. When I add a new dependency in my ivy file I know that it’s not going to be published, so I go to my project Preferences > Java EE Module Dependencies and tick(or untick) any java project that I have in my workspace, apply changes and publish on tomcat and it works!
Somehow this action refreshes something and WTP realises that must update the dependencies.
I didn’t find a way to do a similar trick in Helios.
When I first used ivyDE I remember that all worked to me, I think that in one WTP update stopped to work but I don’t know when. Maybe it’s time to put a bug in WTP (if it is not already)
I hope you understand me, my english is not really good 😉
January 12th, 2011 7:54 am
I’m sorry to say but this is where commercially developed software almost always performs better: ease of use and functionality! Although it is great what people offer to the community for free, the level of quality and integration leaves MUCH to be desired. Eclipse is sooo buggy and unstable and all these kinds of “little” problems make it that developers spend 20% of their time coding while solving IDE problems for the remainder… Now you tell me again about productivity and open source!
April 21st, 2015 11:42 pm
Absolutely! Couldn’t agree with you more.. Just the fact that your post is from 2011, and today in 2015 the IvyDE problem persists, is enough proof.
BTW can you share your experiences with professional IDEs? Which one would you recommend for Java development and other devs for eventual code deployment in the cloud (AWS)? Thanks.
January 28th, 2011 1:13 am
I found with Ivy that it couldn’t pull multiple dependencies from( in my case Hudson running in) winstone.
I believe the problem still exists. the solution for me was to switch Hudson to running under another container. Perhaps your issue is related, ivy failing to talk with some endpoint or other in a reliable way?
March 23rd, 2011 10:37 am
don’t know who to blame; IvyIde or WTP ? If I go to Properties->Deployment Assembly> Add, I can’t even see Referenced Projects Libraries