ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Mauri" <>
Subject reproducing prior released builds / cascading publishing issues
Date Fri, 03 Dec 2010 20:15:08 GMT
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.


Our traditional approach has been source code control centric (syncing
from labels) and will certainly

work correctly but at the cost of syncing and rebuilding everything. I
want to perform proper due-diligence before caving in.


We want to instead leverage the artifact repository captured the static
revision numbers and minimize the amount of source code control synching

(to the branched root module that has ivy.xml with static revisions only
and any modules needed for dev to work with). 

The desire is to recreate the build their need not be any
recompiling/packaging - using resolveMode="default" will pull the
captured dependencies.


In order for a future build reproduction scenario using this approach
(to recreate the patch build), the updated module *and* it's dependees
all the way to the root(s) have to

also be published so as to update their ivy.xml metadata only (else the
published modules are islands that will not be resolved to...)


The sheer amount of publishing and also having to publish modules where
the artifact is not changing (beyond metadata) is troublesome to me.


Here's a simple example:


In releases-lib-shared repo is A 1.0 -> B 1.0 -> C 1.0  *and* A 2.0 -> B
2.0 -> C 2.0

Imagine that C is like log4j and you want all dependees to use the new

We want to update the first build as C 1.0 is broken so we want to first
create: A 1.0 -> B 1.0 -> C 1.0 and then publish a fixed C 1.1

Well, in order to recreate that build we need something like A 1.1 -> B
1.1 -> C 1.1

Publishing C 1.1 without a B 1.1 (and A 1.1 to B 1.1) that refers to it
will not allow us to recreate using our resolve from the branched root
module approach explained above.


Please confirm that it is inevitable that whenever modules are published
to a release repository that either

a)       the entire ecosystem (root on down) be re-published

b)       the dependency paths (all of them down to C) be calculated and
all of them be republished despite the fact this is a metadata driven
only publish request (no artifact changes)


Is there some other approach or advice about such a common scenario (ivy
really needs the best practices regarding typical scenario's like this
documented :-)


- Rich


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