ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harald Braumann <ha...@unheit.net>
Subject Re: specify versions separate from dependencies
Date Wed, 27 Feb 2008 18:58:31 GMT
On Wed, 27 Feb 2008 19:45:41 +0100
"Xavier Hanin" <xavier.hanin@gmail.com> wrote:

> On Wed, Feb 27, 2008 at 7:32 PM, Harald Braumann <harry@unheit.net>
> wrote:
> 
> > On Wed, 27 Feb 2008 18:51:14 +0100
> > "Xavier Hanin" <xavier.hanin@gmail.com> wrote:
> >
> > > On Wed, Feb 27, 2008 at 6:11 PM, Harald Braumann
> > > <harry@unheit.net> 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

Mime
View raw message