I have implemented Alex's suggestions, and it feels like the cleanest
approach. In the context of the Zip task (and derivatives), FileSets may
have a "source" attribute that specifies a zip file whose entries are added
to the output zip file based on the includes-excludes. ZipFileSets also
support "prefix" and "fullpath" attributes, subsuming the functionality
of PrefixedFileSets. After a bit more testing, I'll submit a patch.
The following example would create an output.jar containing a subset
of utils.jar, and some files from /home/don/weblogic/classes. The entries
would be prefixed with "bea/".
<target name="jartest">
<jar jarfile="output.jar">
<fileset
source="utils.jar"
includes="weblogic/"
excludes="weblogic/utils/jars/,**/reflect/"
prefix="bea"
/>
<fileset
dir="/home/don/weblogic/classes"
includes="com/,utils/"
prefix="bea"
/>
</jar>
</target>
Thanks for everyone's feedback.
-Don
Don Ferguson wrote:
Rosen, Alex wrote:
Filtered jar files don't make sense in many (most?) contexts where
filesets are used (e.g. Delete, Copy, Chmod, Move, ExecOn, Ftp, etc),
so I am a little uncomfortable folding such specialized functionality
into something as generic as FileSets.
I agree, this functionality should only be provided in tasks where it
makes
sense: Zip and derivatives, maybe Copy, etc. But that's a separate
question
from what the name of the element is. Take a look at the current Zip.java
that's in CVS. It defines the class PrefixedFileSet which subclasses
FileSet.
There's also currently both addFileset(PrefixedFileSet) and
addPrefixedFileSet(PrefixedFileSet), which let you use a
PrefixedFileSet as a
<fileset> element and a <prefixedfileset> element, respectively.
(There should
really only be one of these - see below.) The cool thing about Ant is
that just
by changing the method name, you can change the element name.
So even though the jarfilter functionality is specific to Zip/Jar, the
element
name could be either <fileset> or <jarfilter> or whatever. The
disadvantage of
using <fileset> is that a <fileset> element would have different
capabilities
and different possible attributes, depending on which task it was for.
The
advantages were listed in my last message.
I'll look into implementing your proposal
(<fileset source="blah.jar">). I like the fact that it introduces
the least syntatic change (adding one attribute to an existing tag
rather than a whole new tag).
BTW, since the <jarfilter> functionality would work equally well for
zips as
for JARs (both for the source and destination), I would propose that this
functionality go in Zip.java rather than Jar.java, and that the
element be
<zipfileset zip="foo.zip"> or <fileset source="blah.jar"> or something
along
those lines.
Yes, it is actually implemented in the Zip task.
On a separate topic, regardless of the <jarfilter> functionality, we
need to
decide if the <zip> task should use <prefixedfilesets> or just
<filesets>.
Allowing both, as we currently do, is not a great idea, as we talked
about a
few weeks ago. We agreed to go with <prefixedfilesets>, and I'm fine
with it
either way, but I want to double-check to see if Stefan and Pete still
think
this is the way to go, if we have more fileset types as well, like
<zipfileset>, <otherfuturefileset>, etc. I'll submit a patch for
whatever is
decided.
We should not exclude META-INF files altogether. I think the
right thing to do is to keep track of which files are added to
the META-INF directory, and ignore duplicates. Arguably, this
is true for all files in the Jar, not just files in the META-INF
directory.
I believe that, with the current <zip> task, if you try to add the
same file
(from the file system) to a zip twice, it will give an error. I think
we should
follow this lead, and I think it's the right thing - silently picking
one of
the files can cause problems that are hard to track down. I think it's
better
to make it explicit that the same file can't be added twice, and make
the user
add an <exclude> to decide which one to use.
Fair enough.
What I'm more worried about, and what I suspect the author of <jlink> was
worried about, is all the magic stuff that can be in META-INF, like
signature
files, index files, etc., which might not make sense when copied from
one JAR
to another. But I agree, arbitrarily excluding all META-INF files
feels wrong,
so I guess we'll just have to live with it.
--Alex
Thanks for the feedback - very helpful.
-Don
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
