--- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > On Fri, 2 Mar 2007, Matt Benson > <[EMAIL PROTECTED]> 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: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > ____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
