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