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 Mon, 08 Jan 2001 22:20:46 GMT
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">

Thanks for everyone's feedback.


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
>> 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 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 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:
> For additional commands, e-mail:

View raw message