ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glidden, Douglass A" <Douglass.A.Glid...@boeing.com>
Subject RE: Many modules, Many versions
Date Wed, 30 Sep 2009 13:31:04 GMT
It sounds to me like you might want to look into more advanced configuration of your CI server
(or consider using a different one if yours doesn't provide the needed functionality).  Most
modern CI servers allow you to configure project dependencies directly within the CI environment.
 That is, using 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 project I worked on recently
even had the CI server set up (by way of some scripting) to set up and maintain the triggers
automatically based on the ivy file 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 set
up cross-build triggers.

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

-----Original Message-----
From: Brian Matzon [mailto:matzon@certus.dk] 
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 time 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 = (B:1.0.0 & C:1.0.0)
D:1.0.1 = (B:1.0.1 & C:1.0.0)
E = (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 create 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 this 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 order).

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 the exclusive and
confidential use of the named addressee(s) and it may contain legally privileged and confidential
information and/or copyrighted material. Any other distribution, use or reproduction without
the sender's prior consent is unauthorized and strictly prohibited. If you have by coincidence,
mistake or without specific authorization received this e-mail in error, please notify the
sender by e-mail immediately, uphold strict confidentiality and neither read, copy, transfer,
disseminate, disclose nor otherwise make use of its content in any way and delete the material
from your computer.

The content of the e-mail and its attachments is the liability of the individual sender, if
it does not relate to the affairs of Betware.
Betware does not assume any civil or criminal liability should the e-mail or it´s attachments
be virus infected.

Mime
View raw message