ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: archivefileset resources
Date Thu, 22 Mar 2007 05:20:53 GMT
On Wed, 21 Mar 2007, Matt Benson <> wrote:
> --- Stefan Bodewig <> wrote:

>> We would want to have a FileRessource remain a FileRessource even
>> when mapping them - same for the other subclasses of Ressource.
>> Some kind of factory would be needed and using an intferface
>> instead of creating yet another subclass of Ressource (or a couple
>> of them) might help.
> Are you suggesting dynamic proxies here?

Well, at least I thought about them, even though I don't have any
experience with cglib or any other existing library.

> I think this implicit RC mapping question does after
> all differ from Alexey's request;

I don't remember Alexey's request in detail, so you are probably

> however I let myself misunderstand the direction of this thread and
> be led down the path of composing a large diatribe on THAT suject,


> Wrt explicitly mapped resourcecollections I think what is needed is
> a well-known syntax specification for specifying a string
> representation of [resource-type][String to pass to constructor]
> e.g. "file?/foo/bar.baz", "url?", "string?blah
> blah blah".

Ahh, that discussion 8-)

> One may recall this as something I've been after for awhile--I
> consider it the "next step" for resource handling in Ant.  For code
> compartmentalization we could probably add the code to generate a
> Resource from a String to ResourceUtils, but IH would know how to
> use e.g. RU.getResource(Project, String) to set Resource attributes
> (for BC, FileResource would be the default).

I don't think there is anything wrong with that.  We deferred it until
after Ant 1.7.0 but I don't see any reason to not implement it now.

I'll cut the rest of this and respond to it separately in a fresh
thread (tomorrow, I guess, need to make breakfast for my kids now).

> Back to our regularly scheduled content...
>> > But to do this with an interface means its consumers would have
>> > to check for it explicitly; put another way, that all resource
>> > consumers would not immediately benefit.  If we implemented the
>> > name-mapping behavior such that it simple overrode getName(), the
>> > consequent question is why have an interface at all?
>> The interface could provide access to the original name and
>> override getName().
> I think I knew that's what you meant... again, to
> implement MappedResource while remaining a
> FileResource, dynamic... subclasses?  Eek!

Or just have a factory that returns static/anonymous? subclasses of
FileRessource and others.  I want to avoid that we add more concrete
classes to the ressource mix to make things worse.

> Surely we can't go there... maybe we'd better rethink the
> "instanceof FileResource" idiom instead, e.g.
> isFilesystemResource()?

Or throw in an interface that contains getFile() and is implemented by
FileRessource - and modify the "instanceof FileResource" idiom to
"instanceof that new interface".

> But if we simply added isFilesystemResource() to Resource, couldn't
> a MappedResource just delegate to the original?  Might that be
> enough?

You'd also need to delegate getFile if that was possible.  Or
getArchive in case of an ArchiveRessource or ...

>> But before you dare to override getName, better check usage
>> patterns in existing tasks.  I wouldn't be surprised if we still
>> had tasks that used "new File(parentDir, ressource.getName())" or
>> something similar and expected the file to exist.
> I don't know.  I don't think Resources were in extremely wide use
> until the 1.7 branch,

Probably not.

> and again, this is the type of problem that is extremely unlikely to
> simply arise at runtime--the build writer should have plenty of time
> to figure out "doh, <foo> doesn't seem to support X resource...".  I
> think adequate disclaimers and warnings should suffice in these
> cases.

Yes, this might work.  Let's be careful, still.


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

View raw message