You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Shawn Castrianni <Sh...@halliburton.com> on 2008/01/09 19:55:29 UTC

handling multiple modules with different release schedules

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 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.

RE: handling multiple modules with different release schedules

Posted by Shawn Castrianni <Sh...@halliburton.com>.
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 [mailto:xavier.hanin@gmail.com]
Sent: Thursday, January 10, 2008 11:10 AM
To: ivy-user@incubator.apache.org
Subject: Re: handling multiple modules with different release schedules

On Jan 9, 2008 7:55 PM, Shawn Castrianni <Sh...@halliburton.com>
wrote:

> 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.

Xavier

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
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

Re: handling multiple modules with different release schedules

Posted by Xavier Hanin <xa...@gmail.com>.
On Jan 9, 2008 7:55 PM, Shawn Castrianni <Sh...@halliburton.com>
wrote:

> 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.

Xavier

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
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/