Hiya, 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 | o--B | 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. http://www.oopsconsultancy.com/software/xmltask/ 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. Juha 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: http://old.nabble.com/reproducing-prior-released-builds---cascading-publishing-issues-tp30371101p30578649.html Sent from the ivy-user mailing list archive at Nabble.com.
