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. :) Scott -----Original Message----- From: Xavier Hanin [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 27, 2008 9:17 AM To: [email protected] 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > On Wed, 27 Feb 2008 10:27:04 +0100 > > "Xavier Hanin" <[EMAIL PROTECTED]> wrote: > > > > > On Tue, Feb 26, 2008 at 6:46 PM, Harald Braumann <[EMAIL PROTECTED]> > > > 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/
