Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@ant.apache.org
Received-SPF: pass (athena.apache.org: domain of Douglass.A.Glidden@boeing.com
 designates 130.76.32.69 as permitted sender)
From: "Glidden, Douglass A" <Douglass.A.Glidden@boeing.com>
To: "ivy-user@ant.apache.org" <ivy-user@ant.apache.org>
Date: Wed, 30 Sep 2009 08:31:04 -0500
Subject: RE: Many modules, Many versions
Thread-Topic: Many modules, Many versions
Thread-Index: AcpBoiXBSuh7chRdQWiOzkBD/Wd2pgALi87w
Message-ID: 
 <E75F905154E9F64CB9F3AE5AB51165B70277232C53@XCH-MW-11V.mw.nos.boeing.com>
References: <4AC30CBB.9060202@certus.dk>
In-Reply-To: <4AC30CBB.9060202@certus.dk>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

It sounds to me like you might want to look into more advanced configuratio=
n of your CI server (or consider using a different one if yours doesn't pro=
vide the needed functionality).  Most modern CI servers allow you to config=
ure project dependencies directly within the CI environment.  That is, usin=
g your example, a successful new build of B will automatically trigger new =
builds of A and D, which in turn will trigger a new build of E.  One projec=
t I worked on recently even had the CI server set up (by way of some script=
ing) to set up and maintain the triggers automatically based on the ivy fil=
e for each project.  If your dependencies don't change often, that level of=
 automation may be unnecessary, but most CI servers make it very easy to se=
t up cross-build triggers.

Doug Glidden
(703) 317-7523
http://dougglidden.blog.boeing.com

-----Original Message-----
From: Brian Matzon [mailto:matzon@certus.dk]=20
Sent: Wednesday, September 30, 2009 03:46
To: ivy-user@ant.apache.org
Subject: Many modules, Many versions

Hi

We have a system running which has a fair amount of packages. Each package =
is placed in a shared repo once its build from our CI. Our CI build every t=
ime someone commits.
This of course yields a fair amount of packages - which in itself is not a =
problem.

However, when a new package is build, it may be build with a newer version =
of its dependencies, whereas another package is still using the old version=
 of the same dependency.
for example:

A:1.0.0 =3D (B:1.0.0 & C:1.0.0)
D:1.0.1 =3D (B:1.0.1 & C:1.0.0)
E =3D (A:1.0.0 & D:1.0.1)

This will of course mean that we have conflict as we have B in 1.0.0 and
1.0.1 when building E.
Since we cannot force E to use B in 1.0.1 (as this may cause problems for A=
), we are currently forced to validate that A works with B:1.0.1 and then c=
reate a new A:1.0.1 which has the same dependency versions of D.

This makes sense in many ways - however when you have a lot of packages thi=
s gets a bit messy (and tiresome).
I am thinking about creating a full-build target in our CI that will update=
 all packages to use all the latest (it just need to build in a specific or=
der).

But I was wondering if A) I am doing something wrong, B) there are smarter =
ways to cope with this

/matzon

The content of this e-mail, together with any of its attachments, is for th=
e exclusive and confidential use of the named addressee(s) and it may conta=
in legally privileged and confidential information and/or copyrighted mater=
ial. Any other distribution, use or reproduction without the sender's prior=
 consent is unauthorized and strictly prohibited. If you have by coincidenc=
e, mistake or without specific authorization received this e-mail in error,=
 please notify the sender by e-mail immediately, uphold strict confidential=
ity and neither read, copy, transfer, disseminate, disclose nor otherwise m=
ake use of its content in any way and delete the material from your compute=
r.

The content of the e-mail and its attachments is the liability of the indiv=
idual sender, if it does not relate to the affairs of Betware.
Betware does not assume any civil or criminal liability should the e-mail o=
r it=B4s attachments be virus infected.