Last week we had a look at Ivy (and switched Orchestra to Ivy) and here are some comments:
1- Ivy now uses maven2 repositories and ivy repository is no longer maintained
In previous versions Ivy used to use the ivyrep resolver as default public resolver,
but ivyrep is no longer maintained, while maven 2 repository on ibiblio is growing rapidly.
Since Ivy is compatible with maven 2 repository, defaulting to the ibiblio maven 2
repository makes more sense.
When ivy uses pom files from maven2 repositories, it generates an ivy.xml file in the cache. This ivy file contains all the dependencies that were in the pom.
Maybe we can use this generated ivy file as a basis for the files in our ivy repository (for example we can reuse hibernate dependencies defined in a publicly available pom and just adjust them to our needs).
2- An eclipse plugin for Ivy exists (ivyDE). A snapshot version of this module is available. This plugin can be used to automatically generate the eclipse classpath from the ivy.xml file of the project. We can specify in the module the configuration to use in eclipse (runtime, compile, test..)
To install latest IvyDE version compatible with the latest Ivy used to resolve Ivy dependencies, you will need to use a snapshot build, not endorsed by the ASF, available here:
We use this plugin for Orchestra (this way the same packages with the same version are used in eclipse and in ant).
Maybe the eclipse classpath of the PVM can be setup with this plugin ?
3- Orchestra now uses ivy for dependency management, but does not depend on the build project. To remove the dependency on the build project, the 'ivy' and 'clean' ant targets were copied. The ivysettings.xml file and the ivy jar file were copied too.