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). Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
