ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Oster" <>
Subject RE: specify versions separate from dependencies
Date Wed, 27 Feb 2008 16:50:11 GMT
Maybe I'm not seeing the whole picture, but I think this could be
supported in Ivy today (although maybe not as cleanly as you like).
Could you not just make use of the conflict management system (as
previously suggested), by implementing a resolution scheme that took the
"nearest" version in the dependency graph.  That is, If A depends on B
and C and B depends on C, you take A's version of C even if it is older
than Bs (as A's version of C is a shorter path through the dependency
graph than B's is).

The issue you mentioned before with this approach is that there is
potentially no conflict if you just want to specify a hard version of
transitive dependencies, even if there is no conflict.  I think the way
around this is you simple introduce a dependency on the module you want
to override (thus introducing a conflict).  This is a bit of a leaky
abstraction, as your module doesn't directly need this module (just
through transitivity), but I don't see it as a huge issue as to specify
that you require a specific version of a module which you don't directly
depend on, implies to me that you have already leaked that abstraction
(i.e you already know you need it, and want to control the version).

That being said, I would support this being more straight-forwardly
controllable; it's something I looked for when I moved to Ivy.  In terms
of organization would suggest some new dependencyManagement
configuration section should be introduced with contains this
information, as well as the conflict management section as the two are
related, and you would need to specify the semantics of which overrides
the other when your conflict management information is in conflict with
your specific version constraints. :)


-----Original Message-----
From: Xavier Hanin [] 
Sent: Wednesday, February 27, 2008 9:17 AM
Subject: Re: specify versions separate from dependencies

If you update your central properties file each time you publish a new
version, and keep using unexpanded properties for revisions in published
files, it becomes very similar to using latest.integration versions in
published files :-) Except that you can override properties before
the central properties file.

But after trying out how the dependencyManagement feature of maven
works, I think we really need to implement something similar in Ivy. The
dependencyManagement feature let you override the revision of any
dependency, including transitive ones, and this can be useful. This is
really in the spirit of flexibility and control over dependencies that I
usually like with Ivy, and on this I think we have to admit that Maven
Ivy. So I think we should provide a similar feature, as easy to use as
maven's one.


On Wed, Feb 27, 2008 at 2:32 PM, John Gill <> wrote:

> Sorry if this isn't on the right track of what you are asking, and I
> not
> sure I like what I am about to suggest!
> As Xavier stated you can put the revisions of the dependencies in a
> properties file, and I guess there is no reason why you couldn't have
> big properties file with all the revisions in it (which you would have
> maintain somehow which is the bit I don't really like), and then in
> ivy.xml file you can reference the properties that you are actually
> Maybe, what you could also do is use a post-publish-artifact trigger
> would be better if there was a post-publish trigger rather than one
> each
> artifact) to update the central properties file when the new revision
> it is published. It might also be possible to have different
> files for different resolvers for the different releases (unstable,
> experimental). The trigger informs you of the resolver used which
> tell
> you which properties file to update using
> Is this a good idea? A part of me finds it this idea appealing, but I
> not
> convinced it's a good idea. My main problem is that the builds would
> be
> totally reproducible, as the central file would
> be
> under version control.
> On the other hand, maybe I missed the point entirely.
> On Wed, Feb 27, 2008 at 7:53 PM, Harald Braumann <>
> > On Wed, 27 Feb 2008 10:27:04 +0100
> > "Xavier Hanin" <> wrote:
> >
> > > On Tue, Feb 26, 2008 at 6:46 PM, Harald Braumann
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > is it possible with ivy to specify the versions of dependencies
> > > > separate from the actual dependency specification? Similar to
> > > > <dependencyMangement> section in maven's parent pom?
> > >
> > > There is no direct support for this currently in Ivy, what we
> > > suggest is to use properties to specify the revisions, and define
> > > these properties in a separate file. The result is very similar to
> > > the dependency management feature.
> >
> > Fair enough, but like this I can only control direct dependencies.
> > Maybe I should elaborate a bit more about what I want. Please note
> > that I'm only familiar with Maven and only recently started to look
> > into Ivy because I'm not completely satisfied with the former. So I
> > might get the terminology wrong.
> >
> > Consider a project that is made up of multiple independent modules.
> > Then there exists some uber-build, that has all the modules as
> > dependencies and creates an installation package for the whole
> >
> > Many of the dependencies will be present in multiple modules, either
> > directly or indirectly and very often with different versions. If I
> > want to update some dependency, I don't want to go through all my
> > modules and update there but I want to do it in a central place, for
> > both direct and indirect dependencies.
> >
> > The only solution I see so far is to use a separate repository for
> > project. But then I'd have to copy the stuff in there manually from
> > other repositories. Certainly doable, but not as nice as just
> > specifying the versions in a file or some such. Compare this to the
> > Debian repository, where you have one pool with all packages and
> > that specify the actual versions that go into a release (stable,
> > unstable, sid, experimental). It's kind of a partitioning of a
> > repository.
> >
> > Please note that this problem also exists for single modules. Lets
> > I have to dependencies, that both depend on foo. Now I update one
> > dependency, the new version of which depends on a new version of
> > But I don't want to update foo if it's not necessary. Again I would
> > like to be able to specify the versions in a single place.
> >
> > I would be quite surprised if others didn't have the same problems
> > with randomly changing versions of indirect dependencies.
> >
> > Regards,
> > harry
> >
> --
> Regards,
> John Gill

Xavier Hanin - Independent Java Consultant

View raw message