On Wed, Feb 27, 2008 at 5:50 PM, Scott Oster <[EMAIL PROTECTED]> 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:[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/ > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
