Return-Path: Delivered-To: apmail-ant-dev-archive@www.apache.org Received: (qmail 5698 invoked from network); 8 May 2007 13:28:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 8 May 2007 13:28:21 -0000 Received: (qmail 65051 invoked by uid 500); 8 May 2007 13:28:26 -0000 Delivered-To: apmail-ant-dev-archive@ant.apache.org Received: (qmail 65018 invoked by uid 500); 8 May 2007 13:28:26 -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 65007 invoked by uid 99); 8 May 2007 13:28:26 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 May 2007 06:28:26 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of xavier.hanin@gmail.com designates 64.233.162.238 as permitted sender) Received: from [64.233.162.238] (HELO nz-out-0506.google.com) (64.233.162.238) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 May 2007 06:28:18 -0700 Received: by nz-out-0506.google.com with SMTP id j2so2015211nzf for ; Tue, 08 May 2007 06:27:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=secAy/SCB0siznp4JZvF0qT7huS1UT9yPtEoEXVio/9f2rmAXcOaRo7OgFW7KN/61twVVCiltWWDQJMnR+BlltqDe85cdzNqNdJYZ9VvbOlR9CS+1LutyyAtStsffIG64f/Kt9Vgho6etoIUyfjfMh816WgkX1ZFT3MrXyQeoHw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ClxgIg0EVoPg1fwn+pdeCTDwhAvFzCjT3f+0yvMQY1SzzYEB3g6lW0yNsePRXQzXgnJSxlOe0i/lBWK/xNCDg6mcVGL9fpSJl92p+d0IITdr0sYFlR5A6BNuHAQx3WhLdR/x6EKNfhk/5LBpEWyZPKiAbPlKsn2ygkXJGzi3HZU= Received: by 10.115.94.1 with SMTP id w1mr2596758wal.1178630877201; Tue, 08 May 2007 06:27:57 -0700 (PDT) Received: by 10.114.124.8 with HTTP; Tue, 8 May 2007 06:27:56 -0700 (PDT) Message-ID: <635a05060705080627o3e164efds8db3d448613db244@mail.gmail.com> Date: Tue, 8 May 2007 15:27:56 +0200 From: "Xavier Hanin" To: "Ant Developers List" Subject: Re: auto download of antlibs In-Reply-To: <464053A0.40806@apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <635a05060705040521g20a4ccf6ua231a2238db29e06@mail.gmail.com> <463F1E40.4010907@apache.org> <635a05060705070704w5d5f6d32o28054b8fe5bad15a@mail.gmail.com> <464053A0.40806@apache.org> X-Virus-Checked: Checked by ClamAV on apache.org On 5/8/07, Steve Loughran wrote: > Xavier Hanin wrote: > > On 5/7/07, Steve Loughran wrote: > > >> hooking in to a named ivy conf: > >> > >> > > And wher is the version information? And how do we map this package > > name to an organization/module name couple? What do you think of > > providing all information: > > > org="org.example" > > module="example" > > rev="1.3" > > conf="example" /> > > I'd expect all version info to be in ivy.xml; when I declare a > configuration in the declaration, I say which ivy configuration > I want, without any version info embedded in the build files And where is the ivy.xml? > > > >> > >> The trick here would be to make it a no-op if there was already an > >> antlib defined into the namespace. > > Yes, would be a nice trick. > > that's what we would have to add above what is there today. > > >> I'm also thinking of an resource that let's you declare a > >> path inline > >> > >> > > Is it a resource or a resource collection? I'm not familiar with the > > Resource API yet... > > Moreover, where do the module information (org/module/rev) come from? > > Shouldn't we provide them? As a side note, it's very similar to the > > current ivy:cachepath task. The main difference is that ivy:cachepath > > is a task, not a resource. But to be a resource I think we'd need some > > kind of lifecycle management for resources. > > > > class Resource extends ResourceCollection :) > > I do think a resource version of cachepath is exactly what we want. We > dont need a lifecycle for resources either, provided the resource can > track whether it has resolved (or failed to resolve) yet. it just does a > resolution the first time its needed (this is how filepaths work) This shouldn't be too difficult to handle. The most difficult part for us is that this is specific to ant 1.7, so we will have a part of our code base specific to 1.7, and the rest compatible with ant 1.6, so we will have to be very careful not to introduce ant 1.7 dependency in the rest of the code base. - Xavier > > -steve > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org > For additional commands, e-mail: dev-help@ant.apache.org > > -- Xavier Hanin - Independent Java Consultant Manage your dependencies with Ivy! http://incubator.apache.org/ivy/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional commands, e-mail: dev-help@ant.apache.org