On Wed, 27 Feb 2008 19:45:41 +0100 "Xavier Hanin" <[EMAIL PROTECTED]> wrote:
> 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) ACK. > - 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? Yes, that sounds very good. harry
signature.asc
Description: PGP signature
