Ivy and reusing (resolved) dependency information

[Chris Nokes <no...@yahoo.com>]

I've been reviewing both Ivy and Maven features related to dependency 
management.

Maven has a dependency management section.  In this section, dependencies with 
rules (e.g. exclusions) can be setup.  This information can then be referenced 
by child POMs by only including org#module as a dependency.  The revision and 
rules for that dependency are inherited from the parent.  Since Maven 2.0.9, the 
import scope was introduced to allow dependency management information to be 
referenced from any POM, not just the parent.

In Ivy 2.1, I use a development time ivysettings.xml file in my stream and 
declare revision information there.  This allows all projects under development 
in that stream to have consistent revisions.  For example:
ivysettings.xml
junit.rev=4.8.2

ivy.xml
<dependency org="junit" name="junit" rev="${junit.rev}" />

This works nicely.  Unfortunately it doesn't match Maven import or POM 
inheritance because I don't inherit dependency rules 
(excludes/includes/artifacts).  Even the inheritance for revision is nice, you 
only need to configure org#module in the child.

Ivy 2.2 introduces parent Ivy files with extends tag.  If I understand 
correctly, the child files inherits all dependencies.  Considering 1 parent file 
in the stream for several modules under development, inheriting all dependencies 
is not what I am interested in.  And I don't really want to manage "the UI layer 
parent file" and the "domain layer parent file".  I want 1 parent file to define 
the architecture dependencies for all modules in the stream, but let the 
children choose which dependencies they use.  So I guess I could simply be 
asking, can Ivy replicate Maven's import feature?

However, I don't really think Maven's POM Inheritance or import scope is what I 
want either.  If I understand Maven's parent POM/import feature, the 
responsibility for conflict resolution is on the POM author.

I've had this idea for a couple years now regarding multi-module builds, I want 
to declare all external module dependencies in a single ivy file, we'll call 
that the external-modules-ivy.xml.  I then want Ivy to resolve that module.  
Because the external-modules-ivy is resolved, special rules 
(include/exclude/artifact) are applied and conflicts resolved.  So far so good 
... all normal Ivy.  Then from my child ivy module under development, when I 
declare a dependency to an external module I want the dependency branch to be 
obtained from a subset of information in the external-modules-ivy report.  For a 
visualization, consider a module section in an Ivy Report.html, and now consider 
"importing a resolved module section".  All modules under development are 
guaranteed to use the same revision of external modules because Ivy performed 
conflict resolution before the dependency was introduced.  Finally, this could 
lead to very optimized resolve processing for modules under development.

I'm very interested to hear the thoughts from this group.
Thanks,
Chris Nokes


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: Ivy and reusing (resolved) dependency information

[Nicolas Lalevée <ni...@hibnet.org>]

Le 2 juin 2011 à 00:40, Chris Nokes a écrit :

> I've been reviewing both Ivy and Maven features related to dependency 
> management.
> 
> Maven has a dependency management section.  In this section, dependencies with 
> rules (e.g. exclusions) can be setup.  This information can then be referenced 
> by child POMs by only including org#module as a dependency.  The revision and 
> rules for that dependency are inherited from the parent.  Since Maven 2.0.9, the 
> import scope was introduced to allow dependency management information to be 
> referenced from any POM, not just the parent.
> 
> In Ivy 2.1, I use a development time ivysettings.xml file in my stream and 
> declare revision information there.  This allows all projects under development 
> in that stream to have consistent revisions.  For example:
> ivysettings.xml
> junit.rev=4.8.2
> 
> ivy.xml
> <dependency org="junit" name="junit" rev="${junit.rev}" />
> 
> This works nicely.  Unfortunately it doesn't match Maven import or POM 
> inheritance because I don't inherit dependency rules 
> (excludes/includes/artifacts).  Even the inheritance for revision is nice, you 
> only need to configure org#module in the child.
> 
> Ivy 2.2 introduces parent Ivy files with extends tag.  If I understand 
> correctly, the child files inherits all dependencies.  Considering 1 parent file 
> in the stream for several modules under development, inheriting all dependencies 
> is not what I am interested in.  And I don't really want to manage "the UI layer 
> parent file" and the "domain layer parent file".  I want 1 parent file to define 
> the architecture dependencies for all modules in the stream, but let the 
> children choose which dependencies they use.  So I guess I could simply be 
> asking, can Ivy replicate Maven's import feature?
> 
> However, I don't really think Maven's POM Inheritance or import scope is what I 
> want either.  If I understand Maven's parent POM/import feature, the 
> responsibility for conflict resolution is on the POM author.
> 
> I've had this idea for a couple years now regarding multi-module builds, I want 
> to declare all external module dependencies in a single ivy file, we'll call 
> that the external-modules-ivy.xml.  I then want Ivy to resolve that module.  
> Because the external-modules-ivy is resolved, special rules 
> (include/exclude/artifact) are applied and conflicts resolved.  So far so good 
> ... all normal Ivy.  Then from my child ivy module under development, when I 
> declare a dependency to an external module I want the dependency branch to be 
> obtained from a subset of information in the external-modules-ivy report.  For a 
> visualization, consider a module section in an Ivy Report.html, and now consider 
> "importing a resolved module section".  All modules under development are 
> guaranteed to use the same revision of external modules because Ivy performed 
> conflict resolution before the dependency was introduced.  Finally, this could 
> lead to very optimized resolve processing for modules under development.

This make me think of the way Eclipse plugins and OSGi Bundle in general are developed. Because of the indirection it exists between the Import-Package requirement and the actual resolved bundle, developing an Eclipse plugins is always done on a "target platform". A target platform is basically an Eclipse install in which there is a bunch of Eclipse plugins jars. So The resolve of a bundle in development is done not against a repository of jar but a subset (and already resolved) of jars.
I even think that dependency management should probably evolve to that kind of resolve workflow. I did a french presentation about it at the Toulouse Jug [1].

Implementation wise, I don't know how to do it yet. Maybe the xml resolve report file could help. It is created on an ivy resolve against a repository. Maybe we can have additional ant tasks which would extract paths from that file.

Nicolas

[1] http://www.slideshare.net/hibnico/mavenivy-vs-osgi-toulouse-jug-26052011


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org