On Wed, 27 Feb 2008 17:41:43 +0100 "Xavier Hanin" <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 27, 2008 at 5:33 PM, Harald Braumann <[EMAIL PROTECTED]>
> wrote:
>
> > On Wed, 27 Feb 2008 16:50:43 +0100
> > "Xavier Hanin" <[EMAIL PROTECTED]> 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
signature.asc
Description: PGP signature
