> -----Original Message-----
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, 26 September 2006 12:56 PM
> To: dev@ant.apache.org
> Subject: Re: Resource.getURL()
>
> On Tue, 26 Sep 2006, Stephen McConnell <[EMAIL PROTECTED]> wrote:
> >> From: Matt Benson [mailto:[EMAIL PROTECTED]
>
> >> Path's inheritance hierarchy was altered such that its immediate
> >> superclass is the new Union resource collection. So the only
> >> difference between the two is, for all practical purposes, the
> >> filesystem-only restriction.
> >
> > Meaning that tasks such as javac (and others) that take classpath
> > definitions as Path arguments could be changed to take a
> Union as an
> > argument?
>
> If you look through Ant 1.7.0 you will see that most tasks
> that supported <filesets> or <paths> or ... now support
> arbitrary resource collections. Tasks that supported nested
> <path> elements in Ant 1.6.5 now automatically support nested
> resources as child elements of that <path>.
>
> In the case of <javac> the compiler itself doesn't deal with
> anything but file resources, so the tasks must ensure only
> Fileresources are added - and <path> guarantees just that.
To translate this into my thinking:
* any child resource of a Path needs to be resolvable to
a local file when dealing with tools such as
javac, java, etc.
As such, some resource are implicitly file based (e.g. FileResource) while
other resources may (or may not) be resolvable to a local file. The
important distinction here is that Path should allow any type of resource
that is resolvable to a local file (but which is not necessarily a file
resource). However - there is nothing in the definition of Resource that
allows an implementation to return a local file. Instead the current model
assumes that only FileResource is a valid source of a local file. Perhaps
this is where I'm running into grief - I have resources that are expressed
as URLs that are resolvable to local files (if necessary) but the current
distinction made between FileResource and anything else prevents their
potential inclusion in path constructs.
This could be resolved by separating the concern of local file resolvability
via a interface dedicated to this concern .. E.g.
public interface LocalFileProvider
{
File getFile();
}
Such an interface could be implemented by FileResource and optionally
implemented by any other resource class - and the Path implementation could
do a if( foo instanceof LocalFileProvider ) ... before accessing the local
file value. In addition changes would be required to Path to allow the
inclusion of file-providing resource children, e.g.
<path id="foo">
<pathelement resource="abc:def"/> <!-- must implement LocalFileProvider
-->
</path>
Does this sound reasonable?
Cheers, Steve.
--------------------------
Stephen McConnell
mailto:[EMAIL PROTECTED]
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
