ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: handling multiple modules with different release schedules
Date Thu, 10 Jan 2008 17:09:54 GMT
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

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