The “war” plugin very much appears to generate WAR-files which are not valid JAR-files and cannot be unpacked with e.g. the command line “jar” utility.
File names in e.g. non-“US-ASCII” can no longer be used. I strongly suspect, that the “war”-plugin uses a generic ZIP-library. ZIP-files and libraries handling and creating ZIP-files use the platform default encoding (like e.g. C1252 on Windows). In JAR-files - and WAR-files, which of course are valid JAR-files - file names are always “UTF-8”.
The problem can be circumvented by a brute force hack involving setting the global “file.encoding” of the VM while running gradle and the “war” plugin. This implies that the table of files may be encoded differently (as is the case on Windows).
The symptom of WARs not being in good order is that e.g. the command line "jar -xvf " on Java SE 6 starts to unpack individual files one by one and ends up with a stack-trace like -
java.lang.IllegalArgumentException
at java.util.zip.ZipInputStream.getUTF8String(ZipInputStream.java:329)
at java.util.zip.ZipInputStream.getFileName(ZipInputStream.java:448)
at java.util.zip.ZipInputStream.readLOC(ZipInputStream.java:267)
at java.util.zip.ZipInputStream.getNextEntry(ZipInputStream.java:93)
at sun.tools.jar.Main.extract(Main.java:862)
at sun.tools.jar.Main.run(Main.java:254)
at sun.tools.jar.Main.main(Main.java:1161)
- or on Java SE 7 something equivalent involving af detailed message including “MALFORMED” like -
java.lang.IllegalArgumentException: MALFORMED
at java.util.zip.ZipCoder.toString(ZipCoder.java:58)
at java.util.zip.ZipCoder.toStringUTF8(ZipCoder.java:117)
at java.util.zip.ZipInputStream.readLOC(ZipInputStream.java:297)
at java.util.zip.ZipInputStream.getNextEntry(ZipInputStream.java:121)
at sun.tools.jar.Main.extract(Main.java:875)
at sun.tools.jar.Main.run(Main.java:263)
at sun.tools.jar.Main.main(Main.java:1177)
Both stack-traces indicate that “reading bytes as a UTF-8 encoded string” fails.
To recreate, use the “war” plugin of Gradle 2.0 and include a file with non-“US-ASCII” characters on a non-“UTF-8” platform (like Windows using Cp1252, which at best has an overlapping with e.g. ISO-8859-1, but not UTF-8) - then try to inspect the resulting WAR-file using e.g. the command-line “jar” utility.
As I said - it very much appears to be so. Should another explanation exist then I am eager to hear about it.