gt; 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 from there.
> >
> > What this would mean is that all the "relative" stuff will be
On Tue, 29 Nov 2005, Peter Reilly <[EMAIL PROTECTED]> wrote:
> The current file attribute of the import task is meant to act
> in the same way as href in html- - i.e relative to the
> directory that the importer file is in.
>
> THe import task could easily use urls in the same way - but
> some in
On Tue, 29 Nov 2005, Steve Loughran <[EMAIL PROTECTED]> wrote:
> I believe that 'hierarchy' is a feature of protocols within a URL,
> which ftp, http, jar, file: support, but things like urn: uuid: that
> handle system thing, they dont.
Yes, hierarchical vs. opaque URLs if my recollection of read
> -Original Message-
> From: Matt Benson [mailto:[EMAIL PROTECTED]
> Just out of curiosity, how many people other than Peter and
> myself have ever started to modify to allow non-file
> imports? :)
I've been using an extended import task for a while now. The task basically
takes
On 11/29/05, Dominique Devienne <[EMAIL PROTECTED]> wrote:
>
>
>
> The two issues I faced when creating large multi-build files builds were:
> 1) Easily refer to the files to import arbitrarily deep in the file
> hierarchy.
> 2) Easily use "resources" relative to the imported builds,
>for furth
> I believe that 'hierarchy' is a feature of protocols within a URL, which
> ftp, http, jar, file: support, but things like urn: uuid: that handle
> system thing, they dont.
I don't believe the JDK and the URL class support these other
protocols out-of-the-box either ;-) The RFC mentioned in the J
Dominique Devienne wrote:
Just out of curiosity, how many people other than
Peter and myself have ever started to modify
to allow non-file imports? :)
I haven't ;-)
The two issues I faced when creating large multi-build files builds were:
1) Easily refer to the files to import arbitrarily d
Mike Rettig wrote:
//the basedir is the implied root
http://localhost/buildfiles"; file="build/mybuild.xml"/>
I vote for deprecating the current import task in favor of a new version
that works consistently with URL's. This allows for backwards compatibility,
and creates consistency with html
Dominique Devienne wrote:
Now how do I get the parent? You can parse the path manually, but a URL can
be a jar resource, HTTP address, file location, newsgroup, partial url, etc.
http://archive.ncsa.uiuc.edu/SDG/Software/Mosaic/Demo/url-primer.html
Rather than parsing the path, it's easier and
> Just out of curiosity, how many people other than
> Peter and myself have ever started to modify
> to allow non-file imports? :)
I haven't ;-)
The two issues I faced when creating large multi-build files builds were:
1) Easily refer to the files to import arbitrarily deep in the file hierarch
> We could add some macro task that copies the resources into a cache directory
> and then applies the from there.
>
> What this would mean is that all the "relative" stuff will be relative to the
> cache location. Something like:
>
>
>
>
>
> The macro will use to put it in the cache and th
> > D:\org_apache>java MakeUrl http://foo/common.xml misc.xml
> > http://foo/misc.xml
> Yes, this works as long as the first file you reference is at the root
> level. This can be confusing in scripts since the root is dictated by that
> first import and not made explicit. Sometimes I want to impor
On 11/29/05, Dominique Devienne <[EMAIL PROTECTED]> wrote:
>
> D:\org_apache>java MakeUrl http://foo/common.xml misc.xml
> http://foo/misc.xml
>
>
Yes, this works as long as the first file you reference is at the root
level. This can be confusing in scripts since the root is dictated by that
first
> Now how do I get the parent? You can parse the path manually, but a URL can
> be a jar resource, HTTP address, file location, newsgroup, partial url, etc.
>
> http://archive.ncsa.uiuc.edu/SDG/Software/Mosaic/Demo/url-primer.html
>
> Rather than parsing the path, it's easier and more explicit to s
URL url = ... construct a URL
Now how do I get the parent? You can parse the path manually, but a URL can
be a jar resource, HTTP address, file location, newsgroup, partial url, etc.
http://archive.ncsa.uiuc.edu/SDG/Software/Mosaic/Demo/url-primer.html
Rather than parsing the path, it's easier a
> A URL has no concept of a 'parent'.
I beg to disagree. If it didn't, the web wouldn't work ;-)
Here's the proof, in this URL contructor: URL(URL context, String spec). --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For addit
> The current file attribute of the import task is meant to act
> in the same way as href in html- - i.e relative to the
> directory that the importer file is in.
>
> THe import task could easily use urls in the same way - but
> some internals in ant assume that build files are Files and
> only Fil
I've worked with the import task quite a bit, and I believe resolving
imports by relativity to the parent file works fine and is intuitive. I
import many shared build files from different working directories and all
build files resolve as expected. This makes the build files easy to reuse
across bu
The current file attribute of the import task is meant to act
in the same way as href in html- - i.e relative to the
directory that the importer file is in.
THe import task could easily use urls in the same way - but
some internals in ant assume that build files are Files and
only Files.
Peter
O
[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 from there.
&g
> You could just do this:
> http://${myhost}/commons.xml";
> dest="${user.home}/.ant/commons.xml"
> usetimestamp="true"/>
>
That's the first level of import I describe. But if common.xml refers
(imports) to misc.xml also located at http://${myhost}/, but you must
also it explicit
--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> On 11/29/05, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
> > It would fit better into Ant´s future if the
> existing would
> > support - e.g. s.
>
> We've had this debate before...
>
> I'd be all for allowing to resources
> instead of fil
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 bu
The macro will use 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
>
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 would
> support - e.g. s.
We've had this debate before...
I'd be all for allowing to resources instead of files, except
for the way was designed to not do things relative to its
p
26 matches
Mail list logo
