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 17:11:29 GMT
On Wed, 27 Feb 2008 17:41:43 +0100
"Xavier Hanin" <xavier.hanin@gmail.com> wrote:

> On Wed, Feb 27, 2008 at 5:33 PM, Harald Braumann <harry@unheit.net>
> wrote:
> 
> > On Wed, 27 Feb 2008 16:50:43 +0100
> > "Xavier Hanin" <xavier.hanin@gmail.com> wrote:
> >
> > > BTW, I think that changing the dependency resolution algorithm in
> > > a 2.0.xrelease is pretty strange. This can easily break builds,
> > > which I wouldn't
> > > suspect when upgrading on a 2.0.x stream.
> > Well, you're not alone there.
> >
> > > > Maybe similar to a virtual module? It could then be specified by
> > > > org/name/etc. just like dependencies.
> > >
> > > What do you mean by similar to a virtual module? Virtual module in
> > > Ivy has a specific sense: it's a module which doesn't publish any
> > > artifact. But maybe you're not referencing to this concept.
> >
> > I am. I just wanted to suggest that it shouldn't be a settings file
> > but something like a module file.
> >
> > > Personnally I was just thinking about something very similar to
> > > maven dependency management feature, with slight adaptation to
> > > Ivy syntax.
> > >
> > > Something like:
> > > <ivy-module version="2.0">
> > >   <info ... />
> > >   <dependencies>
> > >   </dependencies>
> > >   <dependencyManagement>
> > >     <dependency org="foo" name="bar" rev="1.0"  />
> > >   </dependencyManagement>
> > > </ivy-module>
> >
> > So in this case foo-bar-1.0 could actually be a virtual module, but
> > as it is specified under dependencyManagement, it wouldn't pull in
> > the dependencies but just override the versions.
> 
> I'm not sure of what you mean. foo#bar is module, on which we suppose
> the module defined with the ivy.xml define above  depends indirectly.
> Let's suppose we have foo#baz;2.0 -> foo#bar;1.0.1. With this ivy.xml:
> <ivy-module version="2.0">
>   <info organisation="acme" name="mymodule"  />
>   <dependencies>
>     <dependency org="foo" name="baz" rev="2.0"  />
>   </dependencies>
>   <dependencyManagement>
>     <dependency org="foo" name="bar" rev="1.0"  />
>   </dependencyManagement>
> </ivy-module>
> 
> Ivy would resolve the dependency closure as: { foo#baz;2.0 ,
> foo#bar;1.0 } instead of { foo#baz;2.0 , foo#bar;1.0.1 }, because of
> the dependencyManagement section. This is very similar to how Maven
> handle this, right?

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.

harry

Mime
View raw message