ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Gill" <llign...@gmail.com>
Subject Re: specify versions separate from dependencies
Date Wed, 27 Feb 2008 14:21:21 GMT
Hm, yes you're right. I knew there was a reason why the idea didn't feel
right. I was about to write a prototype implementation. I won't bother now
:-)

On Wed, Feb 27, 2008 at 11:17 PM, Xavier Hanin <xavier.hanin@gmail.com>
wrote:

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



-- 
Regards,
John Gill

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