Comments on Ivy

[porcherg]

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

http://incubator.apache.org/ivy/history/2.0.0-alpha2/release-notes.html

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..)

http://incubator.apache.org/ivy/history/trunk/dev.html

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:
http://people.apache.org/~xavier/ivyde/snapshot/

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.

Regards,
Guillaume

[tom.baeyens]

"porcherg" wrote:
1- Ivy now uses maven2 repositories and ivy repository is no longer maintained

http://incubator.apache.org/ivy/history/2.0.0-alpha2/release-notes.html

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).

We should only use external (meaning not under our control) in case those libraries have no further transitive dependencies and if those libraries are very stable.

Since that is a rare combination, I am in favour of maintaining our own ivy repository. That gives us much more control. Instead of trying to get our build to work with other people's ivy files, we can just update them if we have control over them.

If what you're saying is a way to translate public pom files into our own version of the ivy files, that might be a good technique to get started. But I would have to look at the result to evaluate it properly.

[tom.baeyens]

"porcherg" wrote:
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..)

http://incubator.apache.org/ivy/history/trunk/dev.html

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:
http://people.apache.org/~xavier/ivyde/snapshot/

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 ?

Yes. Didn't try the plugin yet cause I wanted to understand what I was doing.

In the scenario that you describe, do I *need* the ivy plugin to build ? Or is the ivy plugin only needed when the classpath needs to be updated based on a changed ivy file ?

[tom.baeyens]

"porcherg" wrote:
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.

I don't think that maintaining copies of ivysettings.xml and ivy.jar is practical.

Maybe, we need to upload those files into the repository. And download them with ant's get to the user home directory in case they are not yet present as a kind of bootstrap.

What do you guys think ?

[porcherg]

If what you're saying is a way to translate public pom files into our own version of the ivy files, that might be a good technique to get started. But I would have to look at the result to evaluate it properly.

This is what I meant when I spoke about the ivy files generated in the cache.

In the scenario that you describe, do I *need* the ivy plugin to build ? Or is the ivy plugin only needed when the classpath needs to be updated based on a changed ivy file ?

The plugin defines a classpath container for eclipse. When used, the only entry to the .classpath file is something like:

<classpathentry kind="con" path="org.apache.ivyde.eclipse.cpcontainer.IVYDE_CONTAINER/ivy.xml/*"/>

If the plugin is not installed, Eclipse can't build the project. So you need the plugin to build the project in eclipse.
This plugin just resolves the dependencies the way ivy does when invoked from ant, and this way we have the same libs in eclipse and in ant builds.

This plugin is only for eclipse and you can build the project from ant without this plugin.

Guillaume