ivy problem and fix submission

[Ed Burcher <ed...@gmail.com>]

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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org