ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Dabbs <>
Subject RE: JLink vs. Jar
Date Mon, 08 Jan 2001 23:07:30 GMT
Since we're talking about FileSet sourcing, I've written an addition to
FileSet that allows it to read include file patterns from a
java.util.Manifest file. I am building my project based upon an explicit
list of source files in manifest file format. In addition, I have a working
MD5-based dependency digest scheme similar to that employed by CONS if this
is of interest.  It calculates the digest of the file and factors in
environmental information such as Java version, classpath and other options
that affect the need to recompile. I am using it to build Ant itself and it
seems to work pretty well so far.


 -----Original Message-----
From: 	Don Ferguson [] 
Sent:	Monday, January 08, 2001 4:21 PM
Subject:	Re: JLink vs. Jar

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:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message