ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject Re: A groovy frontend for Ant
Date Mon, 28 Sep 2009 19:06:38 GMT

Le 28 sept. 09 à 17:32, Stefan Bodewig a écrit :

> On 2009-09-27, Nicolas Lalevée <> wrote:
>> Just one thing is worrying me: the ProjectHelper#parse method is
>> expecting an Object as source, which as the javadoc specifies it can
>> be a File, an URL, an InputStream, or even a specialized type as
>> InputSource. Does it really used with something else than a File or  
>> an
>> URL ?
> No, we don't do so, but it has been asked for a couple of times.  The
> main thing holding back an implementation that was using URLs or  
> streams
> is "what should be use to resolve relative file names".

I read again the javadoc about URL, and more specifically URI (added  
in java 1.4 so it would be OK now for Ant). There is a function to  
resolve a relative path: URI#resolve(URI). So everywhere Ant would  
manage URI until it has to get the content of the pointed file. It  
then resolves the URI relatively to the context (basedir for instance  
should be an URI too). As the URI is absolute it will get the URL:  
URI#toURL(). And finally get the content of that file, and in some  
case of referencing some build file, it would call  

I didn't read the referenced RFC 2396 thought. I don't know what  
exactly does that resolve of relative URI.
And it may change Ant quite a bit too.
Just me thinking loud :)

>> Should we continue to support that ? Shouldn't we better support only
>> URL ? something that we can get content from and have a name.
> Imagine you want tp import a build file that's located in a  
> database ...

Then I would imagine that this file would be described as an URL like  
And there would some URLStreamHandler in the class path that can  
handle that kind of URL.

But then I wonder what relative path would mean in a such case...

>> And by the way shouldn't ProjectHelper be an abstract class ?
> Prior to Ant 1.6.0 ProjectHelper was the actual implemtation used by
> Ant.  I think we kept it non-abstract in order to allow code that
> directly instantiated ProjectHelper to compile.  I'm not sure whether
> any such code ever existed and whether it is still relevant.  Would we
> gain anything from making ProjectHelper abstract?

The only minor gain would be about making the parse method abstract,  
using the java language constructs rather than throwing a  
Let's keep API backward compatibility.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message