ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: archivefileset resources
Date Thu, 22 Mar 2007 15:28:20 GMT
whew, I'll try this:  :)

--- Stefan Bodewig <> wrote:

> 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.

Yep, me neither, but as I think I wrote and you
snipped from what I've seen you earn what you get from
cglib.  In case that doesn't come across well to
non-native speakers (or otherwise; sometimes nobody
understands me) I am saying I think cglib deserves
respect from a functional standpoint and it can and
will do a lot for you (as evidenced by Spring and
Hibernate), but it would take a lot of research on
your part to understand how to make cglib do what you
want it to do.  Maybe I don't have a firm enough
grounding in class structures, etc. though and it's
not as bad as I think, or maybe I'm just an idiot. 
Plus it's been awhile.  In any event, when I looked at
it I ran.  ;)

> > 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
> right.

Basically a mapped fileset... I think we could
extrapolate mapped resource collection, and I think
the string resource representation could take this a
long way.

> 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).

As you say, another discussion.  Hope your kids were
nutritiously fed and I look forward to your separate
email... ;)

> > 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".

That gives me a nice comfy feeling.  If we simply
mandate that this type of Resource classification
should always be interface-defined (we probably should
have done this from the beginning and I'll accept at
least 70% of the responsibility for that), we can use
JDK1.3 proxies and avoid cglib, the very mention of
which made me whimper in fear due to its high learning
curve and the fact that it would be a dependency that
would probably have been mandatory, at least for all
practical purposes.

> > 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 ...

All moot I think simply by saying that getFile() is
defined in an interface.  Ahh...

Another cool thing seems to be that we could provide
some kind of ResourceCollection that could proxy the
resources from another collection but provide their
content in files even for non-file resources for
compatibility with things that required files.  This
would probably take some doing to make it actually
useful, but might be interesting.

> >> 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.

Okay.  :)


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

No need to miss a message. Get email on-the-go 
with Yahoo! Mail for Mobile. Get started. 

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

View raw message