Hi all

i'd like to draw your attention to an inconsistency bug in Ivy  (IVY-1300)

Recently we wanted to use Ivy to help us decompose a system into functional 
modules. By doing this we could organically replace functional blocks (for some 
this was needed for stability and quality reasons). It must be said that ivy 
was prescribed, as we already use it elsewhere. However, that didn't mean we 
couldn't improve on the way other project teams use ivy.
The result is that we have a modular build based on ivy, where we have gone the 
extra mile to use it fully. For example, we use ivy (triggers) to help us 
recursively branch / promote releases (in the case of branch, this happens in 
ivy and Subversion simultaneously). One of the keys to this is the use of ivy 
extra attributes to ensure that we store in the published metadata the svn 
root, branch and revision that was complied to produce the module. At a system 
level, although we don't publish full-system assemblies (deployment packages) 
to ivy, we do describe the assemblies using system-level ivy descriptors - and 
these get published to a metadata-only repository so that we can reassemble 
later if need be. 
In general we have reached a very cool state with ivy, and - it must be said - 
some carefully crafted bespoke ant build scripts.
In amongst all this we use ivy branches, and in fact the most recent aspect of 
things is the automatic, recursive dual-branching (ivy+svn) of all transitive 
dependencies of an assembly ivy descriptor.  

An error made during testing of some of this build system brought to light this 
issue (IVY-1300) that seems pretty serious. When branches are involved, it is 
possible (from the same resolve) to retrieve revision X of a jar, and then 
deliver a descriptor that says that we would have had revision Y. As I 
described, we rely on the published *assembly descriptor* to be the absolute 
truth of what was selected by ivy (as the 'latest.integration') etc. It 
entirely undermines the repeatability of the build-assemble-deploy process if 
the metadata is inaccurate.

So - please take a look at IVY-1300. I've contributed not only a test case (via 
a patch) but also a proposed fix (via a second patch). I am very keen to see it 
fixed. On that subject - Is there a timeline for Ivy 2.3.0 ???

Thanks

Ed 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Reply via email to