Why don't you use the ivy:deliver task which has an attribute 
'replacedynamicrev' for this purpose?

<ivy:deliver replacedynamicrev="true" ... />

Or am I missing something?

regards,
Maarten




----- Original Message ----
From: Michael Shea <m...@nitido.com>
To: dev@ant.apache.org
Sent: Tue, January 12, 2010 9:25:00 PM
Subject: possible ivy contribution: explicit dependency ivy.xml generation.

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 ant.apache.org/ivy, 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 process.

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

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

Now, if we run a release at a given point in time, dependency A.name 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 problem.

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

Thanks,


Mike Shea.

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


      

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

Reply via email to