ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: archivefileset resources
Date Wed, 21 Mar 2007 12:17:33 GMT

--- Stefan Bodewig <bodewig@apache.org> wrote:

> Sorry for dropping the ball.
> 
Not a problem.  To add another metaphor to the
conversation, my plate's been so full lately I seem to
be dropping various balls...  ;)

> On Tue, 6 Mar 2007, Matt Benson
> <gudnabrsam@yahoo.com> wrote:
> > --- Stefan Bodewig <bodewig@apache.org> wrote:
> 
> >> If you go that route, could you please extract
> the supporting
> >> methods into an interface that would allow other
> implementations to
> >> return ressources that change their names when
> used?  Something
> >> like
> >> 
> >> <mappedressource>
> >>   <fileset refid="foo"/>
> >>   <globmapper from="*.java" to="*.class"/>
> >> </mappedressource>
> >> 
> >> which would return all files from the fileset and
> map the names of
> >> them (by returning Ressources that implement the
> new interface).
> > 
> > This sounds like the feature Alexey has been
> demanding
> > all these years.  ;)
> 
> Possibly.  But it is a bit tricky, I'm afraid.
> 
> 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?

I think this implicit RC mapping question does after
all differ from Alexey's request; however I let myself
misunderstand the direction of this thread and be led
down the path of composing a large diatribe on THAT
suject, which follows:  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?http://www.apache.org", "string?blah blah blah". 
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).  This is to all intents and purposes the
only way, IMHO, to seriously take advantage in Ant
tasks of our early decision to design
getOutputStream() into the Resource contract.  You'll
notice my use of the "?" character above to indicate
the preceding text was the name of a currently
available type.  I used "?" because for xmlns as well
as fs reasons I'm pretty sure this character should
NOT be a colon.  However I'm not sure what the RIGHT
"trigger character" is and IMO this is the only
outstanding question stopping us from adding this
feature to Ant.  Aside from allowing IH to transform a
String into a given Resource, you'll see that tasks
using mappers can choose to pass the mapped names to
this same factory code and work with resources, or
they can behave as normal and they will break if a
user tries to map to an arbitrary resource type
(assuming its string representation can't be
misinterpreted as a file, a situation I hope we'll be
able to prevent esp. by choosing the right "trigger
character").

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!  Surely we
can't go there... maybe we'd better rethink the
"instanceof FileResource" idiom instead, e.g.
isFilesystemResource()?  Fortunately Resource is a
class instead of an interface which greatly increases
our freedom.  Then again, because Resource is a class
we pretty much have no choice but to use dynamic
subclasses if we must go this route.  cglib
dependencies, plus have you seen cglib?  There's no
javadoc--obviously the lib works but I certainly
wasn't able to fathom it.  But if we simply added
isFilesystemResource() to Resource, couldn't a
MappedResource just delegate to the original?  Might
that be enough?

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

-Matt

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




 
____________________________________________________________________________________
Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=list&sid=396546091

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


Mime
View raw message