ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harald Braumann <>
Subject Re: specify versions separate from dependencies
Date Wed, 27 Feb 2008 19:08:39 GMT
On Wed, 27 Feb 2008 13:25:01 -0500
"Scott Oster" <> wrote:

> Point taken on the desire to not use the work around; I was just
> suggesting it as an, albeit suboptimal, way to work with the support
> that is there today.
> On your second point about writing a tool to automatically specify the
> versions, I'm not sure I really see the point of using a system like
> Ivy if you want to "hard specify" every single version of all your
> dependencies. 
First of all, I can use all of ivy's power to create
that versions file. A task that is really hard to do manually. The
dependency resolution is just moved from each ant invocation to a
specific "integrate a new dependency" step. Also I can have a central
repository to share the work and there is meta-data attached to the
modules, which I would lose if I just copy libraries in a local lib/

> If you don't do "all" of them, you are left with the
> same potential need for automatic conflict resolution, as some new
> version of a module may introduce a new conflict, which you don't
> have a hard specified rule.
I would never do automatic conflict resolution. A conflict has to lead
to a build error, in which case I would resolve the conflict manually.
I can do this with the conflicts/manager section, but, as posted in
another mail, I would like to have support for multi-module projects.

> Therefore, I think what is needed is the ability to provide Ivy with
> mediation/arbitration rules which are consulted at the time when
> decisions are being made on which versions to use for transitive
> dependencies.  Currently Ivy supports plugging in logic to the
> decision only when there is a conflict; what is missing is just a way
> to plug in logic when there aren't conflicts.  I think a new section
> in the Ivy file which contains the current "conflicts" section, and a
> new "versioncontraints" section would suffice.  
Fair enough. whatever best fits the ivy philosophy.

> I agree with other
> posts "dependencyManagement" is a poor and confusing name for such a
> section, but don't really have many better suggestions, but feel the
> name should be derived from the fact that it's a place to provide
> rules to the engine when processing transitive dependencies.  A
> "manager" syntax similar to "conflicts" would probably suffice.  You
> could then implement your own versioncontraints manager to read a
> "versions file" if you liked; others could simply hard-code the
> versions they want for specific transitive dependencies.
> Scott

View raw message