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 Tue, 06 Mar 2007 12:52:53 GMT

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

> On Fri, 2 Mar 2007, Matt Benson
> <gudnabrsam@yahoo.com> wrote:
> 
> > I noticed that in order to pick the archivefileset
> parameters on
> > e.g. <tar> (I'm assuming zip and family work this
> way as well) the
> > archivefileset has to be a direct child of the
> archive task.  This
> > means that specifying e.g.
> > 
> > <resources id="archiveResources">
> >   <fileset dir="foo" excludes="bar" />
> >   <tarfileset file="bar" fullpath="special/bar" />
> > </resources>
> > 
> > doesn't work as I would expect.
> 
> True.  The prefix and fullpath attributes only work
> in tasks that have
> special handling for ArchiveFileSets and those in
> turn need to know
> there is a ArchiveFileSet somewhere nested in them -
> which they don't
> if you wrap the fileset.
> 
> > Is it agreed that <tar>'s ignoring the fullpath of
> bar is
> > undesirable?
> 
> +1
> 
> > If so it would seem we'd need perhaps an
> ArchiveResource interface
> > to carry along the parameters from the parent
> ArchiveFileSet, etc.,
> > etc?
> 
> They already carry the permission bits so adding the
> prefix and
> fullpath stuff seems logical (don't know why I
> didn't add them right
> away).
> 
> Maybe a single method would even be enough and we
> don't need to have
> separate accessors for fullpath and prefix.  Just a
> different getName
> method (don't know how to call it) that returned the
> name after
> fullpath or prefix has been applied.
> 
> 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.  ;)  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?  Possibly to provide
access to the original resource name?  WDYT?

-Matt

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



 
____________________________________________________________________________________
Yahoo! Music Unlimited
Access over 1 million songs.
http://music.yahoo.com/unlimited

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


Mime
View raw message