Return-Path: 
 <dev-return-84980-apmail-ant-dev-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-dev-archive@www.apache.org
Received: (qmail 14950 invoked from network); 12 Jan 2010 21:14:54 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 12 Jan 2010 21:14:54 -0000
Received: (qmail 95549 invoked by uid 500); 12 Jan 2010 21:14:54 -0000
Delivered-To: apmail-ant-dev-archive@ant.apache.org
Received: (qmail 95452 invoked by uid 500); 12 Jan 2010 21:14:54 -0000
Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@ant.apache.org>
List-Help: <mailto:dev-help@ant.apache.org>
List-Post: <mailto:dev@ant.apache.org>
List-Id: "Ant Developers List" <dev.ant.apache.org>
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Delivered-To: mailing list dev@ant.apache.org
Received: (qmail 95442 invoked by uid 99); 12 Jan 2010 21:14:54 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Jan 2010 21:14:54 +0000
X-ASF-Spam-Status: No, hits=1.2 required=10.0
	tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [206.223.166.205] (HELO mailserv.nitido.com) (206.223.166.205)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Jan 2010 21:14:47 +0000
Received: from [192.168.13.68] (unknown [192.168.13.68])
	by mailserv.nitido.com (Postfix) with ESMTP id 498E7A52048B
	for <dev@ant.apache.org>; Tue, 12 Jan 2010 16:14:26 -0500 (EST)
Message-ID: <4B4CE65C.7080701@nitido.com>
Date: Tue, 12 Jan 2010 16:15:08 -0500
From: Michael Shea <mike@nitido.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Ant Developers List <dev@ant.apache.org>
Subject: Re: possible ivy contribution: explicit dependency ivy.xml
 generation.
References: <4B4CDA9C.7070301@nitido.com>
 <667881.82409.qm@web30802.mail.mud.yahoo.com>
In-Reply-To: <667881.82409.qm@web30802.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

That would answer my question, "Is there something out there that=20
already does it?".

Thanks,


Shea.
> Why don't you use the ivy:deliver task which has an attribute 'replaced=
ynamicrev' for this purpose?
>
> <ivy:deliver replacedynamicrev=3D"true" ... />
>
> Or am I missing something?
>
> regards,
> Maarten
>
>
>
>
> ----- Original Message ----
> From: Michael Shea <mike@nitido.com>
> To: dev@ant.apache.org
> Sent: Tue, January 12, 2010 9:25:00 PM
> Subject: possible ivy contribution: explicit dependency ivy.xml generat=
ion.
>
> Hi folks,
>
> I am not sure if this is the right list to post this on (but it is list=
ed as the Ivy development mailing list on ant.apache.org/ivy, so I'm pres=
uming that it is).
>
> I have been working recently on an ant task to generate what I am refer=
ring to as "explicit ivy.xml files". What I mean by this is that I want t=
o generate an ivy.xml file containing all the same configurations as the =
original ivy.xml file, but which forces revisions to the exact versions t=
hat resolved at build time. This (or something equivalent) is necessary a=
t my company in order for us to have a reproducible release process.
>
> I will illustrate the problem. Suppose you have the following ivy.xml f=
ile:
>
> <ivy-module version=3D"2.0">
>   ...
>   <dependencies>
>      <dependency org=3D"A" name=3D"name" rev=3D"1.+" conf=3D"default->*=
"/>
>   </dependencies>
> </ivy-module>
>
> Now, if we run a release at a given point in time, dependency A.name mi=
ght resolve to "1.2". But later on, it might resolve to "1.3" if a new ve=
rsion is published. This problem can be solved in several ways - you coul=
d simply have release configurations in which you disallow the "1.+" nota=
tion, for instance, or you can just look at the generated XML or HTML rep=
orts from <ivy: report/>, and use these to manually reconstruct a new ivy=
=2Exml 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 use=
s the force attribute on dependencies, and sets the rev attributes to the=
 actual versions that got resolved, for all dependencies (including trans=
itive ones). It also includes appropriate "conf" attrbiutes on the depend=
encies. I believe this will solve the problem.
>
> I'm just wondering: Do people think this is a good idea? Is there somet=
hing out there that already does it? I originally tried using the xsl tra=
nsformations of the ivy report XML, but that didn't work for me because i=
t seemed to generate one report per configuration (and I wanted one repor=
t *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 ge=
tting the latest Ivy sourcecode and extending IvyPostResolveTask.
>
> Thanks,
>
>
> Mike Shea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
>      =20
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>  =20



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