ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Shea <>
Subject possible ivy contribution: explicit dependency ivy.xml generation.
Date Tue, 12 Jan 2010 20:25:00 GMT
Hi folks,

I am not sure if this is the right list to post this on (but it is 
listed as the Ivy development mailing list on, so I'm 
presuming that it is).

I have been working recently on an ant task to generate what I am 
referring to as "explicit ivy.xml files". What I mean by this is that I 
want to generate an ivy.xml file containing all the same configurations 
as the original ivy.xml file, but which forces revisions to the exact 
versions that resolved at build time. This (or something equivalent) is 
necessary at my company in order for us to have a reproducible release 

I will illustrate the problem. Suppose you have the following ivy.xml file:

<ivy-module version="2.0">
      <dependency org="A" name="name" rev="1.+" conf="default->*"/>

Now, if we run a release at a given point in time, dependency 
might resolve to "1.2". But later on, it might resolve to "1.3" if a new 
version is published. This problem can be solved in several ways - you 
could simply have release configurations in which you disallow the "1.+" 
notation, for instance, or you can just look at the generated XML or 
HTML reports from <ivy: report/>, and use these to manually reconstruct 
a new ivy.xml file. However, I have tried to solve the problem by 
writing my own ant task which looks at the ResolveReport (so it needs to 
be run after a call to <ivy:report/>). This task generates a new ivy.xml 
file which uses the force attribute on dependencies, and sets the rev 
attributes to the actual versions that got resolved, for all 
dependencies (including transitive ones). It also includes appropriate 
"conf" attrbiutes on the dependencies. I believe this will solve the 

I'm just wondering: Do people think this is a good idea? Is there 
something out there that already does it? I originally tried using the 
xsl transformations of the ivy report XML, but that didn't work for me 
because it seemed to generate one report per configuration (and I wanted 
one report *for all configurations*). Anyway - if this is a useful 
thing, how can I go about contributing it back to the Ivy project? Fyi, 
I wrote it by getting the latest Ivy sourcecode and extending 


Mike Shea.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message