ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Tharp <>
Subject Re: Many modules, Many versions
Date Wed, 30 Sep 2009 13:36:27 GMT
I use Hudson and the Ivy plugin for this type of cascading of builds.
However, if you are specifying specific revisions in your ivy files for your
other modules (instead of something like 1.0.+) then simply triggering other
builds will not solve your problem.


On Wed, Sep 30, 2009 at 6:31 AM, Glidden, Douglass A <> wrote:

> 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
> -----Original Message-----
> From: Brian Matzon []
> Sent: Wednesday, September 30, 2009 03:46
> To:
> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message