ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kyle Adams" <>
Subject Re: Skipping empty JARs
Date Fri, 04 Jan 2002 20:48:08 GMT
> Why?  I don't understand the reason for this change, and the cvs log 
> entry isn't very helpful.  Finally, this change means I'm ending up with a 
> bunch of empty JARs in my classpath, and makes it a lot harder to 
> create a generalized build script for use on multiple projects.

Now that I've had a chance to look through the Bugzilla for this bug 
(#4448), I'd like to add a little more.

The comment attached to the request for a fix on this behavior was, "One 
can argue, that jars are never empty, as they must always contain at
least a manifest - I think this is the logic behind the current behavior."

This doesn't make sense to me at all.  To begin with, the jar tool allows 
creation of a jar without a manifest file (through the -M switch).  Secondly, 
there are situations where a jar may be truly empty (no manifest, no files), but because of
the current implementation, Ant makes something from nothing (auto-generates a manifest file)
and creates what should be a 
non-existent (skipped) jar file.

In short, ignoring the -M switch, the statement above is correct.  Jars are never empty, as
they must contain at least a manifest.  Which means that 
if there's no user-specified manifest, and no files, the jar shouldn't even be 
created.  This was the functionality in Ant 1.3, and it seems really odd to remove it for
Ant 1.4.

Some might wonder, "why call the jar task when there's no need for a jar 
to begin with?"

The answer: sometimes creation of a jar is conditional on which project is 
being built.  I used the "skip" functionality to create a generalized Ant script for our company's
various Java apps.  Most of them create A.jar, some of them create B.jar, and a few create
C.jar.  Ant 1.3 (with actual skip functionality) handles the generalized script very nicely.
 Under Ant 1.4, I'd either have to write my own jar task to re-implement the 
setWhenempty() function, or set up separate targets for each jar and put 
in the appropriate <available> tasks - both kludgy solutions.

I don't see what the harm is in allowing the Jar task to skip the creation of 
a truly empty (no user-specified manifest, no files) archive, and removing 
that functionality seems to be a step backwards.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message