On Wed, Feb 27, 2008 at 7:32 PM, Harald Braumann <[EMAIL PROTECTED]> wrote:
> On Wed, 27 Feb 2008 18:51:14 +0100 > "Xavier Hanin" <[EMAIL PROTECTED]> wrote: > > > On Wed, Feb 27, 2008 at 6:11 PM, Harald Braumann <[EMAIL PROTECTED]> > > wrote: > > > > > Sorry, I misunderstood you before. You put the overrides in the ivy > > > file directly. In this case you're right, of course. I thought of > > > foo#bar more like the parent pom in maven nomenclature. > > > > > > In your proposal it would be nice, if dependencyManagement would be > > > resolved recursively. This would help multi-module projects, where > > > you want to define versions centrally in a single file. You could > > > then specify a module without publications (thus I thought of a > > > virtual module) and with only a dependencyMangement section. Like > > > so: > > > > > > <ivy-module version="2.0"> > > > <info organisation="acme" name="myproject" /> > > > <dependencies> > > > </dependencies> > > > <dependencyManagement> > > > <dependency org="foo" name="bar" rev="1.0" /> > > > <dependency org="foo" name="baz" rev="1.0" /> > > > </dependencyManagement> > > > </ivy-module> > > > > > > <ivy-module version="2.0"> > > > <info organisation="acme" name="mymodule1" /> > > > <dependencies> > > > ... > > > </dependencies> > > > <dependencyManagement> > > > <dependency org="acme" name="myproject" > > > rev="latest.integration" /> </dependencyManagement> > > > </ivy-module> > > > > > > <ivy-module version="2.0"> > > > <info organisation="acme" name="mymodule2" /> > > > <dependencies> > > > ... > > > </dependencies> > > > <dependencyManagement> > > > <dependency org="acme" name="myproject" > > > rev="latest.integration" /> </dependencyManagement> > > > </ivy-module> > > > > > > And thus both, mymodule1 and mymodule2, would use the same versions > > > of foo#bar and foo#baz. > > > > I'm not sure to follow you. In acme#myproject, the > > dependencyManagement section is used to override dependencies, ok. > > But then in acme#mymodule(1|2) it's used (with the same syntax) as a > > kind of import or include mechanism, right? How do we distinguish > > between the two? > In the same way as it is done with dependencies. If mymodule1 depends > on foo#bar, it uses foo#bar and at the same time includes all the > dependencies of foo#bar, recursively. Similarly, mymodule1 overrides > any dependency of acme#myproject (acme#myproject is just meant as a > helper module to specify overrides in a single file, so its probably > not useful for any package to really depend on it) and additionally > includes all overrides from acme#myproject. I still have a problem to envision how we could code that: in my mind, when Ivy finds a "dependencyManagement" (better name to be chosen) section, it fills a data structure which is used when resolving dependencies transitively. But it doesn't actually resolve this as a dependency. So Ivy has no way to know that you actually want to resolve acme#myproject, and use its dependencyManagement section. What I could understand is if you'd use a different syntax to inform you want to use the dependencyManagement section of myproject, or if you use a regular dependency on myproject. For the latter, I wouldn't like to see this, since it would mean that a dependency (myproject) could influence the way other dependencies from the depender are resolved. You can answer that this is already the case when there's a conflict, but it's a different case, because conflict management end up to the depender's responsibility, even though this is hidden in most cases. But I think we have a pretty decent solution: - add a new section (good name still to be found) allowing to define dependency overrides (revision, branch, extra attributes) - add a kind of parent/include mechanism (but only for root ivy files being resolved, files in repository would be merged to avoid complex location mechanism) Does it sound good? Xavier > > harry > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
