ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject Re: Ivy and reusing (resolved) dependency information
Date Wed, 08 Jun 2011 09:21:23 GMT

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.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message