Why distZip rather than fat jar?

Help/Discuss
1

I’m wondering about the architectural decisions around the distribution plugin, in particular why the distZip / distTar formats were created.

It seems that the main advantage of the distribution plugin is that you get a single binary artefact which contains all of the application’s dependencies and runs on any system. However, the format comes with some (minor) disadvantages:

  • It has to be unzipped on the target system
  • It requires different scripts for *nix and windows systems, and relies on shell / windows bat to construct the java invocation
  • There are issues with the maximum path length on windows
  • (presumably) Runs into the same issues as fat jars where it has to decide between dependencies at different versions that want to have the same filename.

It seems to me that the fat jar approach used in maven-shade and others also solves the single-binary-artefact problem in a more elegant way, but I’m sure I’m missing some nuances.

What was the reasoning for choosing to use the distZip format rather than going down a fat jar route?

2

The distribution infrastructure is generic, not Java specific. It can be used for native software too for instance.

There is the excellent shadow plugin which produces fat jars if you prefer those. Since such a plugin already exists and is well maintained we didn’t include one in Gradle itself.

3

The zip format is useful when you want to be able to edit configuration without unzipping/re-zipping jar files. It’s quite common to have a conf or config folder in the zip which is added to the classpath (in the .bat and/or .sh scripts). Once the distZip is unzipped you can tweak property files, log4j config etc in this folder and bounce the application without needing to unpack/repack a jar file

1 Like