ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Castrianni <>
Subject RE: handling multiple modules with different release schedules
Date Thu, 10 Jan 2008 17:44:22 GMT
Yes, you misunderstood.  The A1 release wasn't meant to mean A release 1 in terms of an ivy
release/build number but like a company's product release to the public.  I just used A1 as
a make believe name like Microsoft's Chicago or Longhorn release name.

Let's try this.  Let's say Microsoft uses ivy for its Office, Windows, IE, and .NET sotware
product releases.  Let's say that these products are broken up into modules in which some
are shared amongst each other.  So a GDI module might be used by Windows and IE.  A CRT module
might be used by .NET and Office.  And maybe an XML might be used by all software products.
 Let's say that Microsoft will have 4 releases to the public this year, one each quarter.
 The first quarter release will have Windows and IE in it.  The second quarter release will
have Office, .NET, and IE.  Etc...

With such a large coporation with so many modules each on its own release schedule, where
any given module is a member of multiple releases releasing at different times, what is a
good way to organize ivy artifacts and repositories?  Should you have a different repository
for each public release such that all modules involved in that release are in that repository
and are compatible with each other?

I realize that this is a big question, but I guess I am curious if anyone out there has used
ivy in a large corporation with all of this complication and how they leveraged ivy's features
to keep everybody's dependencies straight?

Shawn Castrianni

-----Original Message-----
From: Xavier Hanin []
Sent: Thursday, January 10, 2008 11:10 AM
Subject: Re: handling multiple modules with different release schedules

On Jan 9, 2008 7:55 PM, Shawn Castrianni <>

> I am trying to manage around 30 modules where each, in theory, could be on
> a different release schedule.  In practice, different groups of these
> modules release together.  For my following example, let's pretend each
> module does not have any transitive dependencies and that each dependency is
> in the ivy.xml file as a direct dependency.  Let's  say, module A for its
> A1 release may need the latest version of modules B, C, and D

What do you mean by latest version? Once A is released as A;1, do you still
want to say its dependencies are latest versions? This means that whenever
you publish a new version of B A;1 will always be "compatible" with it? It
sounds rather strange to me, I must misunderstand what you mean.


and the specific E2 released version of module E and specific F5 released
> version of module F.  Module A for its A2 release may need the release
> version B2 of B, the latest of C, D, E, and F.  Module B for its B2 release
> needs etc....
> How do I efficiently handle all of this mess?  Do I make a separate
> repository for each module's release such that only the correct versions of
> each dependent module for that release are in that repository and then
> switch out the resolver depending on which release is being built?  Do I
> make my own custom statuses for each module's release and then just
> reference latest.[releaseName] as the dependency version all coming from the
> same repository?  Do I write my own resolver that handles all of this
> internally?
> Any suggestions or past experience would help greatly.
> ---
> Shawn Castrianni
> ----------------------------------------------------------------------
> This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient.  Any
> review, use, distribution, or disclosure by others is strictly prohibited.
>  If you are not the intended recipient (or authorized to receive information
> for the intended recipient), please contact the sender by reply e-mail and
> delete all copies of this message.

Xavier Hanin - Independent Java Consultant

View raw message