Return-Path: Delivered-To: apmail-ant-dev-archive@www.apache.org Received: (qmail 460 invoked from network); 12 Jan 2010 20:31:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 12 Jan 2010 20:31:41 -0000 Received: (qmail 24655 invoked by uid 500); 12 Jan 2010 20:31:40 -0000 Delivered-To: apmail-ant-dev-archive@ant.apache.org Received: (qmail 24563 invoked by uid 500); 12 Jan 2010 20:31:40 -0000 Mailing-List: contact dev-help@ant.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list dev@ant.apache.org Received: (qmail 24553 invoked by uid 99); 12 Jan 2010 20:31:40 -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 20:31:40 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [68.142.200.145] (HELO web30802.mail.mud.yahoo.com) (68.142.200.145) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 12 Jan 2010 20:31:33 +0000 Received: (qmail 84094 invoked by uid 60001); 12 Jan 2010 20:31:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1263328271; bh=NEXbaF4FD9Z3vIWTQS7gs78sNGd7xrG1ugDnH1GnP0k=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=zHXnlouv8NZ2bb7g1+QFgIX6bdgmkxvJ5PvtZAnB7Am7Qyq87Oku7k9tgmG7b2RBGS5BiCDnxBdN6TNpEGw7FxbqFVJAm/DK1KjEI2oX2wiEgXGWo4FQjyQT/yjjMpEBy/qRkKKBLvhuqWX/GZy4Wmg6nSjp1Woimy8REqfot4E= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=5Kip12j9hUZAcgb/0G5dCgAGheDtdmHscfvvzKqXcorRpEA1gyinDDVIL8S/ZUO5B/QpC4HP0XSG1xyhFjZNPXzfLqcD+VyoGaEYonIr6fioWWbs+qi+ztKUKNjCpItOeV1LvUY8xkjSoWe+3andfPC/CyXblKVc6S6GftdkRZU=; Message-ID: <667881.82409.qm@web30802.mail.mud.yahoo.com> X-YMail-OSG: laCy3xAVM1nNAW1FUEmxIDwm9MNAmjQqQfw1n3ZOn.y3p1t1j4DZCjDQM.1kuwxtxnH6AzoweYbbYdsckH5L1H8pdwG7lTkFATd58w3BjJlw73y0GGAdFZRlKyboR8Xp5OkL8v.NI_.m5ylwqn3abAPtn_qxIvG7_n9wceUIzBetz.v2kTNtQOVnnQ7BrEPx6qpd0PASKI0XGWkRMEiQNhCccXU4Igo.kfxF6UvSbksGIEZoYul8.X.IxNf2EaQky86H9Foxx28QzLQ9_IYcIPY7_4uV5HmqsR5nTRCopjV.INOzfkO.TBRePdR1rpbUpki4ApaAV_X2L34Ip8sRVOAl1nHXof9_Q1W.o4wP0awEDLrmg4hSmI9fmeoBrf42pXEha.b9jWvBSiaXPTVBYZ.EB2UANqR1quV4qt1qWz2dZvRgyVPWLM9CEbfx1H1N2UrVk3SRLEWO9Ci378cstmwx3ARMfCFQrX50xDo- Received: from [81.240.69.49] by web30802.mail.mud.yahoo.com via HTTP; Tue, 12 Jan 2010 12:31:11 PST X-Mailer: YahooMailRC/240.3 YahooMailWebService/0.8.100.260964 References: <4B4CDA9C.7070301@nitido.com> Date: Tue, 12 Jan 2010 12:31:11 -0800 (PST) From: Maarten Coene Subject: Re: possible ivy contribution: explicit dependency ivy.xml generation. To: Ant Developers List In-Reply-To: <4B4CDA9C.7070301@nitido.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Why don't you use the ivy:deliver task which has an attribute 'replacedynamicrev' for this purpose? Or am I missing something? regards, Maarten ----- Original Message ---- From: Michael Shea 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: ... 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 , 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 ). 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-unsubscribe@ant.apache.org For additional commands, e-mail: dev-help@ant.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional commands, e-mail: dev-help@ant.apache.org