Return-Path: 
 <dev-return-70174-apmail-ant-dev-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-dev-archive@www.apache.org
Received: (qmail 26632 invoked from network); 29 Nov 2005 15:48:16 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 29 Nov 2005 15:48:16 -0000
Received: (qmail 72316 invoked by uid 500); 29 Nov 2005 15:48:15 -0000
Delivered-To: apmail-ant-dev-archive@ant.apache.org
Received: (qmail 72135 invoked by uid 500); 29 Nov 2005 15:48:14 -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 72124 invoked by uid 99); 29 Nov 2005 15:48:14 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Nov 2005 07:48:14 -0800
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: domain of mike.rettig@gmail.com designates
 64.233.162.206 as permitted sender)
Received: from [64.233.162.206] (HELO zproxy.gmail.com) (64.233.162.206)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Nov 2005 07:49:44 -0800
Received: by zproxy.gmail.com with SMTP id 34so182825nzf
        for <dev@ant.apache.org>; Tue, 29 Nov 2005 07:47:53 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=F8Tua9s7n3Ace59GU20eCDSC4KA6Kur/c0VD83odGWeUdv2WTzBQ8LDMOUncVTKAkCG6xruw3361O6jtNFv87zDu8Z+SqxBqFgxuAEkRCCcy2MgBipdd4wBZicleFxQsHqtihzBc3riu2V0t9QbqsaOxeoMpjaB/J/8qsjD6RFw=
Received: by 10.65.15.10 with SMTP id s10mr3913416qbi;
        Tue, 29 Nov 2005 07:47:52 -0800 (PST)
Received: by 10.64.21.1 with HTTP; Tue, 29 Nov 2005 07:47:52 -0800 (PST)
Message-ID: <7c47dffa0511290747v211bc7d5y7bc994cd81a4602e@mail.gmail.com>
Date: Tue, 29 Nov 2005 09:47:52 -0600
From: Mike Rettig <mike.rettig@gmail.com>
To: Ant Developers List <dev@ant.apache.org>
Subject: Re: Importing and caching build files from a URL
In-Reply-To: <EA9D95F907E2924A9A32F274114BCDEF8680E3@perth.Cellectivity.local>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_64522_27106754.1133279272308"
References: <EA9D95F907E2924A9A32F274114BCDEF8680E3@perth.Cellectivity.local>
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

------=_Part_64522_27106754.1133279272308
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This is what I've done in UrlImport code. I grab the resource and cache it
to ~/.antcache, then load it using the normal import task.

Mike

On 11/29/05, Jose Alberto Fernandez <jalberto@cellectivity.com> wrote:
>
> We could add some macro task that copies the resources into a cache
> directory and then applies the <import> from there.
>
> What this would mean is that all the "relative" stuff will be relative to
> the cache location. Something like:
>
> <fetchimport cache=3Ddir>
>   <resource href=3D"http:...."/>
> </fetchimport>
>
> The macro will use <get> to put it in the cache and then use import on th=
e
> content of the cache.
>
> Would that make sense you think?
>
> Jose Alberto
>
> > -----Original Message-----
> > From: Dominique Devienne [mailto:ddevienne@gmail.com]
> > Sent: 29 November 2005 15:19
> > To: Ant Developers List
> > Subject: Re: Importing and caching build files from a URL
> >
> > On 11/29/05, Jan.Materne@rzf.fin-nrw.de <Jan.Materne@rzf.fin-nrw.de>
> > wrote:
> > > It would fit better into Ant=B4s future if the existing <import> woul=
d
> > > support <resources> - e.g. <urlresource>s.
> >
> > We've had this debate before...
> >
> > I'd be all for allowing to <import> resources instead of files, except
> > for the way <import> was designed to not do things relative to its
> > parent directory, like HTML and XSL hrefs. I can't see how we could
> > have a clean "relative" import model like HTML/XSL while retaining BC.
> > Yes, we could probably import easily a resource of the "first level",
> > but it would be kludgy at best for this imported build to refer to
> > other resources in the same jar file for example.
> >
> > So really we have to choose between limiting ourself to our current
> > design for import, or extend it to resources but in such a way that I
> > feel is unnatural, inconsistent, and a bit of a hack. But maybe I'm
> > just missing the point somewhere, or my view that import is flawed is
> > what flawed in fact ;-) --DD
> >
> > ---------------------------------------------------------------------
> > 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
>
>

------=_Part_64522_27106754.1133279272308--