ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: specify versions separate from dependencies
Date Wed, 27 Feb 2008 18:24:10 GMT
On Wed, Feb 27, 2008 at 5:50 PM, Scott Oster <oster@bmi.osu.edu> wrote:

> 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,

I agree, but I wonder what syntax to use. Do you have any idea?


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

As soon as you specify the dependencyManagement, you override the version
constraint from all dependers, and thus there's no possible conflict.  Hence
I think dependencyManagement should take priority over conflict management.

Xavier

>
>
> Scott
>
> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: Wednesday, February 27, 2008 9:17 AM
> To: ivy-user@ant.apache.org
> 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
> ivy
> files, it becomes very similar to using latest.integration versions in
> your
> published files :-) Except that you can override properties before
> loading
> the central properties file.
>
> But after trying out how the dependencyManagement feature of maven
> actually
> 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
> beats
> Ivy. So I think we should provide a similar feature, as easy to use as
> maven's one.
>
> Xavier
>
> On Wed, Feb 27, 2008 at 2:32 PM, John Gill <llignhoj@gmail.com> wrote:
>
> > Sorry if this isn't on the right track of what you are asking, and I
> am
> > 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
> one
> > big properties file with all the revisions in it (which you would have
> to
> > maintain somehow which is the bit I don't really like), and then in
> your
> > ivy.xml file you can reference the properties that you are actually
> using.
> >
> > Maybe, what you could also do is use a post-publish-artifact trigger
> (it
> > would be better if there was a post-publish trigger rather than one
> for
> > each
> > artifact) to update the central properties file when the new revision
> when
> > it is published. It might also be possible to have different
> properties
> > files for different resolvers for the different releases (unstable,
> sid,
> > experimental). The trigger informs you of the resolver used which
> would
> > tell
> > you which properties file to update using
> >
> > Is this a good idea? A part of me finds it this idea appealing, but I
> am
> > not
> > convinced it's a good idea. My main problem is that the builds would
> not
> > be
> > totally reproducible, as the central revisions.properties file would
> not
> > 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 <harry@unheit.net>
> wrote:
> >
> > > On Wed, 27 Feb 2008 10:27:04 +0100
> > > "Xavier Hanin" <xavier.hanin@gmail.com> wrote:
> > >
> > > > On Tue, Feb 26, 2008 at 6:46 PM, Harald Braumann
> <harry@unheit.net>
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > is it possible with ivy to specify the versions of dependencies
> > > > > separate from the actual dependency specification? Similar to
> the
> > > > > <dependencyMangement> section in maven's parent pom?
> > > >
> > > > There is no direct support for this currently in Ivy, what we
> usually
> > > > 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
> project.
> > >
> > > 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
> the
> > > 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
> files
> > > that specify the actual versions that go into a release (stable,
> > > unstable, sid, experimental). It's kind of a partitioning of a
> central
> > > repository.
> > >
> > > Please note that this problem also exists for single modules. Lets
> say
> > > 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
> foo.
> > > 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
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
>



-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message