ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juha Ranta <>
Subject Re: reproducing prior released builds / cascading publishing issues
Date Mon, 03 Jan 2011 15:04:16 GMT


I'm not sure if this helps, but I'll describe some notes from the
experiences we've had with Ivy and multimodule builds. 

First, it may be useful to group related modules (modules that are often
developed and published together) in a bigger module. The directory
structure in the source code could be something like this:

  * root
  |  build.xml
  o-- A 
  |     build.xml
  |     ivy.xml
  |    build.xml
  |    ivy.xml


Sorry if my ascii graphics don't show right :) 

In the root's build.xml, use the buildlist task to get the right compile
order, then use this list with subant to compile and publish the submodules.
Yes, it publishes all of the submodules every time, but perhaps it's not
that bad; it's how Maven does it as well.

Oh, and use the branch attribute in the ivy.xml info tags, they may become
useful later. 

When the release time comes, create a release branch from root. Modify each
ivy.xml files so that each dependency included in the multimodule (such as
A->B) has rev="latest.integration" branch="RELEASE_1.0" (or whatever) and
each dependency to a common module outside the multimodule has a static
version. BTW, Oopsconsultancy's XMLTask is quite useful for modifying the
ivy.xml files.

Let's say the module C is a common module outside the multimodule (log4j, as
in your example) and A->B->C. If the version of log4j needs to be changed,
you can change it in B and do a new build at the root level. It's build and
publish B and then build and publish A. 

Also, if the module A only needs the new version, perhaps you can add a
direct dependency A->C.

So, this approach requires you to publish all of the modules in the
multimodule for each change, but it's relatively simple to do. I've done a
full recursive promotion build system, but now that I think of it, it's
perhaps too complex for the benefits. 

If anyone else has different approaches to more complex multimodule builds,
release fixes, promotions, etc, I'm happy to hear of them. 


Richard Mauri wrote:
> Greetings ivy-users
> I am outlining a design approach (part of a migration towards
> Ant/Ivy/Artifactory) to address a common
> Release Engineering requirement to reproduce a prior release build in
> preparation for development an upcoming bug fix/patch release.
>  ...

View this message in context:
Sent from the ivy-user mailing list archive at

View raw message