[lkrubner]

I agree with this:

"but dependency-free single-binary deployments are very, very convenient"

On a semi-related topic, my first exposure to programming on the JVM was through Clojure, where it is common to use the Leinengen build/dependency manager, and which allows the creation of an uberjar, which offers what you mention, "dependency-free single-binary deployments".

Then I started doing some actual Java development, and I was surprised that uberjars are somewhat uncommon among Java projects. There is a plugin for Maven that allows the creation of uberjars, but many projects use complicated application servers and the co-location of needed jars -- a system that seems complicated and fragile. I ended up using Buildr as my build system, but it doesn't seem to offer an uberjar option, at least nothing as convenient as what is offered by Leinengen. Given the convenience of uberjars, I would think they would be more common Java projects. Apparently they are avoided because so many Java projects are huge (with many thousands of classes) and so a common uberjar pattern (of exploding all dependencies to the same level) runs into the problem of name collisions. Which brings up another issue relevant to Go and Clojure, the small size of many apps, the ease of going with a micro-services architecture, greatly increases the ease of deployment as well.