Re: reproducing prior released builds / cascading publishing issues

[Juha Ranta <ju...@iki.fi>]

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.

Re: reproducing prior released builds / cascading publishing issues

[Martin Eigenbrodt <ma...@googlemail.com>]

That's basically the way I do it. Thanks for the xmltask link. I will give
it a try. Does it retain comments and format? Currentlty I use regex search
and replacement or a custom Ivy task  to modify ivy.xmls for (half-)
automatic branching and releasing.
I use ivy:buildlist to traverse the dependency graph in both directions (As
in your example: for Changes in B autmatically build A which depends on B
and root, or Build root and all its depdendencies).
This might be nitpicking but I would not think of this as "multimodule
Builds"in the maven way. Nothing prevents you from having two ore more
"root" Projects that share some of their subprojects. If you publish an Url
to your SCM within your ivy file you don't even need to have all project
available in the current file system but can fetch everythingh needed for a
build starting with a single ivy.xml.

Martin

2011/1/3 Juha Ranta <ju...@iki.fi>

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