ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: specify versions separate from dependencies
Date Wed, 27 Feb 2008 18:45:41 GMT
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)
- 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/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message