Many modules, Many versions

[Brian Matzon <ma...@certus.dk>]

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.

Re: Many modules, Many versions

[Joshua Tharp <jo...@alumni.calpoly.edu>]

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.

Josh

On Wed, Sep 30, 2009 at 6:31 AM, Glidden, Douglass A <
Douglass.A.Glidden@boeing.com> 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
> 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.
>

RE: Many modules, Many versions

["Glidden, Douglass A" <Do...@boeing.com>]

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.