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
