ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Ferguson <>
Subject Re: JLink vs. Jar
Date Fri, 05 Jan 2001 02:43:35 GMT

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
> 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
> 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 rather than, and that the element be
> <zipfileset 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
> 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.


View raw message