Exactly, my only point is to wrap it on a nice macro definition that allows for processing multiple files and people do not need to think much of what goes on behind the scenes. With docs and stuff.
Ideal for an antlib. :-) Jose Alberto > -----Original Message----- > From: Burgess, Benjamin [mailto:[EMAIL PROTECTED] > > You could just do this: > > <get src="http://${myhost}/commons.xml"; > dest="${user.home}/.ant/commons.xml" > usetimestamp="true"/> > <import file="${user.home}/.ant/commons.xml"/> > > Ben > > -----Original Message----- > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 29, 2005 10:27 AM > To: Ant Developers List > Subject: RE: Importing and caching build files from a URL > > 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=dir> > <resource href="http:...."/> > </fetchimport> > > The macro will use <get> to put it in the cache and then use import on the > content of the cache. > > Would that make sense you think? > > Jose Alberto > > > -----Original Message----- > > From: Dominique Devienne [mailto:[EMAIL PROTECTED] > > Sent: 29 November 2005 15:19 > > To: Ant Developers List > > Subject: Re: Importing and caching build files from a URL > > > > On 11/29/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> > > wrote: > > > It would fit better into Ant´s future if the existing <import> would > > > 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > ************************************************************** > This message, including any attachments, contains confidential information > intended for a specific individual and purpose, and is protected by law. > If you are not the intended recipient, please contact sender immediately > by reply e-mail and destroy all copies. You are hereby notified that any > disclosure, copying, or distribution of this message, or the taking of any > action based on it, is strictly prohibited. > TIAA-CREF > ************************************************************** > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
