Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
From: "Rosen, Alex" <arosen@silverstream.com>
To: ant-dev@jakarta.apache.org
Subject: RE: JLink vs. Jar
Date: Wed, 3 Jan 2001 14:48:39 -0500
Message-ID: <002101c075be$2c29d930$8265810a@silverstream.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <3A521DA0.80402@bea.com>

> 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.

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.

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.

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