You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by "Rosen, Alex" <ar...@silverstream.com> on 2001/01/02 17:33:49 UTC
RE: JLink vs. Jar
I agree. We were thinking about adding similar functionality. It's confusing to
have both <jar> and <jlink> tasks that do similar but different things - I
agree that the <jlink> functionality should be moved into <jar>. Stefan seemed
to disagree though:
Stefan Bodewig <bo...@bost.de> 2000-09-11:
> We shouldn't try to duplicate
> this functionality (adding files to existing .jar files for example)
> in <jar> IMHO. Let's keep <jar> the simple solution that fits most
> situations and point people to <jlink> in the more difficult ones.
To me, this is confusing, and it also presents problems if people want to use
different features at once. E.g. what if you want to use the <war> task but
also want the merging capabilities of <jlink>? And maybe some other feature of
another <jar> derivative in the future? You can't do that unless the common
functionality is in the base <jar> task. Stefan, what do you think?
On the other hand, you do have the problem of how exactly to combine these
pieces of functionality. E.g the <jar> task now can have <prefixedfileset>
children, which are just like <filesets> except that then can specify where in
the target JAR the files should go. (Kind of the complement of your <jarfilter>
functionality.) The question is, can I suck out the contents of a JAR file with
<jarfilter> and place them in a particular subdirectory of the target JAR? If
so, do we need <fileset> <prefixedfileset> <jarfilter> and <prefixedjarfilter>?
The list could expand exponentially. That's why I preferred having just
<fileset>, which would have the special property that it can have certain extra
attributes in certain cases. Then, you could just use <fileset
sourcejar="blah.jar" prefix="web-inf/classes" />.
On a different note, the doc says that "jlink ignores META-INF directories in
mergefiles. Users should supply their own manifest information for the output
file." How do your changes handle this? Should we leave it up to the user to
exclude META-INF, or will this be error-prone? Do we need something ugly like
exclude-meta-inf="false"?
Alex
> -----Original Message-----
> From: Don Ferguson [mailto:don@bea.com]
> Sent: Friday, December 29, 2000 6:49 PM
> To: ant-dev@jakarta.apache.org
> Subject: JLink vs. Jar
>
>
> I have recently begun exploring ant, and have found the JLink
> task to be
> insufficient for my needs, and also, not consistent with other file
> based ant tasks. Specifically, JLink does not provide a mechanism for
> selecting a subset of a jar file via includes/excludes. It also seems
> to me that there is too much overlap in the functionality provided by
> Jar and JLink, so in my copy of the sources, I have modified the Jar
> task to subsume the capabilities of JLink by addition of a new data
> type: JarFilter. The Jar task can include both FileSets and
> JarFilters. A JarFilter extracts a subset of files from the jar using
> the same matching rules as FileSets, and includes these files in the
> output jar. For example, the following would create "myant.jar",
> including my ant classes with the standard ant.jar, but
> excluding JLink:
>
> <?xml version="1.0"?>
>
> <project name="JarExample" default="main" basedir=".">
> <target name="main">
> <jar jarfile="myant.jar">
> <fileset dir="/home/don/classes"
> includes="weblogic/ant/"
> />
> <jarfilter jarfile="/ant/lib/ant.jar"
> includes="org/apache/"
>
> excludes="org/apache/tools/ant/taskdefs/optional/jlink/"
> />
> </jar>
> </target>
> </project>
>
>
> I think this make the Jar task much more useful, but as I'm
> new to ant,
> I'd be curious to hear what others have to say about this approach.
> Comments?
>
> -Don
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
Re: JLink vs. Jar
Posted by Peter Donald <do...@apache.org>.
At 12:38 4/1/01 +0100, Stefan Bodewig wrote:
>Peter Donald <do...@apache.org> wrote:
>
>> Just a FYI but I think that a lot of this functionality will be
>> consolidated into FileSet + Mapper in Ant2.0.[...] Thou this is
>> just a guess from work Stefan did ;)
>
>Huh? I have not read up to the beginning of this thread, I'm jumping
>in somewhere in the middle, sorry. Actually I have not thought about
>associating a mapper to a fileset as closely as you did, but now that
>you mention it ...
>
><prefixedfileset prefix="bla/"> could be something like
>
><fileset ...>
> <mapper type="glob" from="*" to="bla/*" />
></fileset>
>
>a lot more difficult to read but extremely powerful. Not sure.
I guess I just assumed that was the idea ;) I thought you mentioned
something like this with respect to unifying all file handling. ie all
tasks build filesets + mappers and hand em to a utility method that does
dependency checking etc. Maybe it was someone else ... no idea - I have a
relatively bad memory for that sorta thing ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: JLink vs. Jar
Posted by Stefan Bodewig <bo...@apache.org>.
Peter Donald <do...@apache.org> wrote:
> Just a FYI but I think that a lot of this functionality will be
> consolidated into FileSet + Mapper in Ant2.0.[...] Thou this is
> just a guess from work Stefan did ;)
Huh? I have not read up to the beginning of this thread, I'm jumping
in somewhere in the middle, sorry. Actually I have not thought about
associating a mapper to a fileset as closely as you did, but now that
you mention it ...
<prefixedfileset prefix="bla/"> could be something like
<fileset ...>
<mapper type="glob" from="*" to="bla/*" />
</fileset>
a lot more difficult to read but extremely powerful. Not sure.
Stefan
RE: JLink vs. Jar
Posted by Peter Donald <do...@apache.org>.
Just a FYI but I think that a lot of this functionality will be
consolidated into FileSet + Mapper in Ant2.0. So instead of having a
refixedfileset, appendfileset, otherfileset you will just have one fileset
but allow it to be associated with a mapper. Thou this is just a guess from
work Stefan did ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: JLink vs. Jar
Posted by Stefan Bodewig <bo...@apache.org>.
Alex Rosen <ar...@silverstream.com> wrote:
> 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.
I agree to the "as we currently do" part. I'd prefer
addPrefixedfileset(PrefixedFileSet) and addFileset(FileSet) to remove
the confusion. Switching to PrefixedFileSet exclusively is something
you cannot do (at least not for Ant 1.x) as it would break tons of
builds.
>> We should not exclude META-INF files altogether.
Actually I talked to Patrick and Matthew about these issues back in
October. We agreed (IIRC) that the user should explicitely state which
MANIFEST.MF to use, to not merge in signatures at all and to allow for
all other content in META-INF (unless it was a duplicate which would
always be an error).
All that was missing was somebody who had the time to implement it.
Stefan
Re: JLink vs. Jar
Posted by Don Ferguson <do...@bea.com>.
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">
<fileset
source="utils.jar"
includes="weblogic/"
excludes="weblogic/utils/jars/,**/reflect/"
prefix="bea"
/>
<fileset
dir="/home/don/weblogic/classes"
includes="com/,utils/"
prefix="bea"
/>
</jar>
</target>
Thanks for everyone's feedback.
-Don
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 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
Re: JLink vs. Jar
Posted by Don Ferguson <do...@bea.com>.
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
RE: JLink vs. Jar
Posted by "Rosen, Alex" <ar...@silverstream.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
Re: JLink vs. Jar
Posted by Don Ferguson <do...@bea.com>.
Hi. Comments in line.
Rosen, Alex wrote:
> I agree. We were thinking about adding similar functionality. It's confusing to
> have both <jar> and <jlink> tasks that do similar but different things - I
> agree that the <jlink> functionality should be moved into <jar>. Stefan seemed
> to disagree though:
>
> Stefan Bodewig <bo...@bost.de> 2000-09-11:
>
>> We shouldn't try to duplicate
>> this functionality (adding files to existing .jar files for example)
>> in <jar> IMHO. Let's keep <jar> the simple solution that fits most
>> situations and point people to <jlink> in the more difficult ones.
>
>
> To me, this is confusing, and it also presents problems if people want to use
> different features at once. E.g. what if you want to use the <war> task but
> also want the merging capabilities of <jlink>? And maybe some other feature of
> another <jar> derivative in the future? You can't do that unless the common
> functionality is in the base <jar> task. Stefan, what do you think?
>
> On the other hand, you do have the problem of how exactly to combine these
> pieces of functionality. E.g the <jar> task now can have <prefixedfileset>
> children, which are just like <filesets> except that then can specify where in
> the target JAR the files should go. (Kind of the complement of your <jarfilter>
> functionality.) The question is, can I suck out the contents of a JAR file with
> <jarfilter> and place them in a particular subdirectory of the target JAR? If
> so, do we need <fileset> <prefixedfileset> <jarfilter> and <prefixedjarfilter>?
> The list could expand exponentially. That's why I preferred having just
> <fileset>, which would have the special property that it can have certain extra
> attributes in certain cases. Then, you could just use <fileset
> sourcejar="blah.jar" prefix="web-inf/classes" />.
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. Also, I think it may not be
a comfortable fit; I've encountered code that assumes that the
items in a FileSet are individual files on the file system which
is not the case with Jar entries.
Regarding a prefix for the entries, I think it would be appropriate
to add a prefix attribute to jarfilter. I agree that it would be
bad to add a whole new type for this.
>
> On a different note, the doc says that "jlink ignores META-INF directories in
> mergefiles. Users should supply their own manifest information for the output
> file." How do your changes handle this? Should we leave it up to the user to
> exclude META-INF, or will this be error-prone? Do we need something ugly like
> exclude-meta-inf="false"?
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.
>
> Alex
>
>
>> -----Original Message-----
>> From: Don Ferguson [mailto:don@bea.com]
>> Sent: Friday, December 29, 2000 6:49 PM
>> To: ant-dev@jakarta.apache.org
>> Subject: JLink vs. Jar
>>
>>
>> I have recently begun exploring ant, and have found the JLink
>> task to be
>> insufficient for my needs, and also, not consistent with other file
>> based ant tasks. Specifically, JLink does not provide a mechanism for
>> selecting a subset of a jar file via includes/excludes. It also seems
>> to me that there is too much overlap in the functionality provided by
>> Jar and JLink, so in my copy of the sources, I have modified the Jar
>> task to subsume the capabilities of JLink by addition of a new data
>> type: JarFilter. The Jar task can include both FileSets and
>> JarFilters. A JarFilter extracts a subset of files from the jar using
>> the same matching rules as FileSets, and includes these files in the
>> output jar. For example, the following would create "myant.jar",
>> including my ant classes with the standard ant.jar, but
>> excluding JLink:
>>
>> <?xml version="1.0"?>
>>
>> <project name="JarExample" default="main" basedir=".">
>> <target name="main">
>> <jar jarfile="myant.jar">
>> <fileset dir="/home/don/classes"
>> includes="weblogic/ant/"
>> />
>> <jarfilter jarfile="/ant/lib/ant.jar"
>> includes="org/apache/"
>>
>> excludes="org/apache/tools/ant/taskdefs/optional/jlink/"
>> />
>> </jar>
>> </target>
>> </project>
>>
>>
>> I think this make the Jar task much more useful, but as I'm
>> new to ant,
>> I'd be curious to hear what others have to say about this approach.
>> Comments?
>>
>> -Don
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org