Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: softfail (nike.apache.org: transitioning domain of
 nicolas.lalevee@hibnet.org does not designate 216.86.168.183 as permitted
 sender)
Message-Id: <827F6864-9CCE-4E39-8158-53BC9B2F86F4@hibnet.org>
From: =?ISO-8859-1?Q?Nicolas_Lalev=E9e?= <nicolas.lalevee@hibnet.org>
To: "Ant Developers List" <dev@ant.apache.org>
In-Reply-To: <87r5trdqzx.fsf@v35516.1blu.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: A groovy frontend for Ant
Date: Mon, 28 Sep 2009 21:06:38 +0200
References: <200908311042.48291.nicolas.lalevee@hibnet.org>
 <87y6p0c6aj.fsf@v35516.1blu.de>
 <200909011428.43968.nicolas.lalevee@hibnet.org>
 <e802d55e0909110946j3ac48034x326250c6a6f98c21@mail.gmail.com>
 <27A1DD9B-FD1F-4183-9326-4723E19432B4@hibnet.org>
 <3F91FA58-0EE8-4FCA-A0D5-0AE176FF75FF@hibnet.org>
 <87r5trdqzx.fsf@v35516.1blu.de>


Le 28 sept. 09 =E0 17:32, Stefan Bodewig a =E9crit :

> On 2009-09-27, Nicolas Lalev=E9e <nicolas.lalevee@hibnet.org> 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 =20=

>> 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 =20
> streams
> is "what should be use to resolve relative file names".

I read again the javadoc about URL, and more specifically URI (added =20
in java 1.4 so it would be OK now for Ant). There is a function to =20
resolve a relative path: URI#resolve(URI). So everywhere Ant would =20
manage URI until it has to get the content of the pointed file. It =20
then resolves the URI relatively to the context (basedir for instance =20=

should be an URI too). As the URI is absolute it will get the URL: =20
URI#toURL(). And finally get the content of that file, and in some =20
case of referencing some build file, it would call =20
ProjectHelper#parse(URL).

I didn't read the referenced RFC 2396 thought. I don't know what =20
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 =20
> database ...

Then I would imagine that this file would be described as an URL like =20=

db://user:password@host:port/MyDb?select=3D.....
And there would some URLStreamHandler in the class path that can =20
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, =20
using the java language constructs rather than throwing a =20
BuildException.
Let's keep API backward compatibility.


Nicolas


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org