Why your new JVM build tool is making things worse, aka use Maven to execute your build
There are a few principles that I would like the ecosystem of build tool developers to adopt so we can all get on the same page. Here they are in priority order:
- The build tool should be designed to make it as easy as possible for other developers to build your project. The primary consumer of the automated build should not be you. It is your CI machine, it is your fellow developers, and it is your open source users. You could build it with a bespoke shell script much more efficiently.
- There should be a single style of dependency management so that all published artifacts are consumable by any build. The bifurcation into Ivy repositories and Maven repositories makes very little sense. NIH is not a reason to make up a new directory structure.
- Innovation in the space should be around tools that sit in front of a common backend so that the primary developer doesn’t need to change the ecosystem to make their build configuration less verbose.
What does this mean in practice? SBT, gradle, pants, Leinegen — I think you are all doing it wrong. There isn’t much innovation in those projects, they mostly are rebuilding what Maven already gives you with a different language on top — but usually leaving out a ton of features, call out to Maven plugins and add scripting (mistake). If each of them had instead decided that their build tool would generate pom.xml under the covers they would have had instant support from the community (IDEs, CI, users, etc) and could focus on making the very best plugin for their language. Instead they reinvent the wheel. At least in some cases people are starting to reuse Aether from Maven to get around the repository bifurcation and in other cases embracing Maven — Typesafe’s zinc compiler plugin. My opinion is that people can’t see the big picture and are only focusing on themselves to the detriment of the JVM ecosystem.