Return-Path: 
 <ivy-user-return-2594-apmail-ant-ivy-user-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-ivy-user-archive@www.apache.org
Received: (qmail 98413 invoked from network); 27 Feb 2008 18:58:57 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 27 Feb 2008 18:58:57 -0000
Received: (qmail 74827 invoked by uid 500); 27 Feb 2008 18:58:52 -0000
Delivered-To: apmail-ant-ivy-user-archive@ant.apache.org
Received: (qmail 74806 invoked by uid 500); 27 Feb 2008 18:58:52 -0000
Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:ivy-user-help@ant.apache.org>
List-Unsubscribe: <mailto:ivy-user-unsubscribe@ant.apache.org>
List-Post: <mailto:ivy-user@ant.apache.org>
List-Id: <ivy-user.ant.apache.org>
Reply-To: ivy-user@ant.apache.org
Delivered-To: mailing list ivy-user@ant.apache.org
Received: (qmail 74797 invoked by uid 99); 27 Feb 2008 18:58:52 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 27 Feb 2008 10:58:52 -0800
X-ASF-Spam-Status: No, hits=1.2 required=10.0
	tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [87.118.102.170] (HELO km10614-05.keymachine.de)
 (87.118.102.170)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 27 Feb 2008 18:58:18 +0000
Received: from sbs173 (cm66-147.liwest.at [212.241.66.147])
	by km10614-05.keymachine.de (Postfix) with ESMTP id 7B02F2C5265A
	for <ivy-user@ant.apache.org>; Wed, 27 Feb 2008 19:58:26 +0100 (CET)
Date: Wed, 27 Feb 2008 19:58:31 +0100
From: Harald Braumann <harry@unheit.net>
To: ivy-user@ant.apache.org
Subject: Re: specify versions separate from dependencies
Message-ID: <20080227195831.7a908663@sbs173>
In-Reply-To: <635a05060802271045h46515301l1247b42e6df17ebb@mail.gmail.com>
References: <20080226184625.7decc0cd@sbs173>
	<20080227115305.1a40c042@sbs173>
	<635a05060802270523i1512e901xc866a238388be697@mail.gmail.com>
	<20080227160333.58eca9bc@sbs173>
	<635a05060802270750o665fb7au97a03a1c5307c4b7@mail.gmail.com>
	<20080227173349.31f1b8a4@sbs173>
	<635a05060802270841y2088d269w4d8f198ec324eee7@mail.gmail.com>
	<20080227181129.28a53289@sbs173>
	<635a05060802270951vec067e8ubfc7a21d7bbd03a3@mail.gmail.com>
	<20080227193247.76d90509@sbs173>
	<635a05060802271045h46515301l1247b42e6df17ebb@mail.gmail.com>
X-Mailer: Claws Mail 3.3.0 (GTK+ 2.12.5; i486-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="Sig_/omxJZJ1y83iDkgo0OtD3lgK";
 protocol="application/pgp-signature"; micalg=PGP-SHA1
X-Virus-Checked: Checked by ClamAV on apache.org

--Sig_/omxJZJ1y83iDkgo0OtD3lgK
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

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:
>=20
> > 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=3D"2.0">
> > > >   <info organisation=3D"acme" name=3D"myproject"  />
> > > >   <dependencies>
> > > >  </dependencies>
> > > >  <dependencyManagement>
> > > >    <dependency org=3D"foo" name=3D"bar" rev=3D"1.0"  />
> > > >     <dependency org=3D"foo" name=3D"baz" rev=3D"1.0"  />
> > > >  </dependencyManagement>
> > > > </ivy-module>
> > > >
> > > > <ivy-module version=3D"2.0">
> > > >   <info organisation=3D"acme" name=3D"mymodule1"  />
> > > >  <dependencies>
> > > >     ...
> > > >  </dependencies>
> > > >  <dependencyManagement>
> > > >    <dependency org=3D"acme" name=3D"myproject"
> > > > rev=3D"latest.integration"  /> </dependencyManagement>
> > > > </ivy-module>
> > > >
> > > > <ivy-module version=3D"2.0">
> > > >   <info organisation=3D"acme" name=3D"mymodule2"  />
> > > >  <dependencies>
> > > >     ...
> > > >  </dependencies>
> > > >  <dependencyManagement>
> > > >    <dependency org=3D"acme" name=3D"myproject"
> > > > rev=3D"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.
>=20
> 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.
>=20
> 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)
>=20
> Does it sound good?
Yes, that sounds very good.

harry

--Sig_/omxJZJ1y83iDkgo0OtD3lgK
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHxbLXwMFqDB+mz24RAhw6AJkBTbZRG0+xtF6HqD/9tqaooaZ/4QCeP6+8
taYTmeZtD/lDCTqNFU4v0eM=
=1Co6
-----END PGP SIGNATURE-----

--Sig_/omxJZJ1y83iDkgo0OtD3lgK--