Le 28 sept. 09 à 17:32, Stefan Bodewig a écrit :
On 2009-09-27, Nicolas Lalevée <nicolas.lale...@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
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
ProjectHelper#parse(URL).
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
db://user:passw...@host:port/MyDb?select=.....
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
BuildException.
Let's keep API backward compatibility.
Nicolas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
