Mill: A better build tool for Java, Scala, and Kotlin

Ya know, I've directed a lot of criticism at Maven over the years... and most of it well-founded, I believe, even in hindsight. And yet, today, I find that of all the Java build tools, Maven is my preferred one. Part of that is me, normalizing the pain of Maven in some regards, and part of that is places where they have improved the tool. But however you break it down, it is indeed the case that for the most part Maven "just works"™. That is, at least for Java. I don't do a lot of Scala or Kotlin or anything, so no comment there. And for Groovy, I'm usually doing Grails projects which default to Gradle, so I tend to use Gradle in that context. But for plain Java projects, I honestly find Maven to be the path of least resistance.

I've had the misfortune of having Maven forced on me for Scala projects, I just can't agree with you. The overhead of starting the compiler so often is a killer, and makes your builds much slower. Unless there's been some improvement of Zinc/Bloop/Etc with Maven since I've used it.

I think I would prefer to use Mill than Maven (I haven't used Mill myself) ... going through the video tutorial, it's clear that it's also a very simple system without some of the ancient baggage of Maven (xml, too many plugins, etc).

I think you can make it 10 years. It is super robust. It just works for java stuff.

My main problem with Maven is that it's dog slow and incremental compilation doesn't really work, especially on CI. For huge repos that's a real issue.

In a sense I feel that part of the microservice craze is due to the fact that many of our build systems are not good enough to allow us to work with huge monoliths efficiently. Gradle is a bit better (definitely faster), but comes with additional complexity. Haven't tried Mill.

I agree 100%.

I've been around for a while, I've used many different build systems for JVM based builds (Java, Hybrid Java/Clojure, Scala) and Maven is by far the simplest most solid.

The basic reason is it's commitment to being declarative.

I understand why programmers want imperative (we're programmers) but it's just the wrong choice for a build system.

I've worked on many OSS projects. I've never pulled a Maven-based project that didn't immediately build and immediately load into my IDE. However for imperative based build systems (Gradle, Ant, now Mill) it's almost inevitable that you won't be able to get the build to work right away or pulled into your IDE in a sensible way (as IDEs cannot read imperative statemetns).

I've created many many build with Maven with many many different demands (polygot codebase, weird deployment artifacts, weird testing runtime needs, etc etc) and Maven has never let me down. Yes, in some cases I've had to write my own plugin but it was good that I had to do that; it forced me to ensure I really needed to -- the Maven plugin ecosystem is already great and covers 90+% of use cases of builds.

I've met a lot of Maven naysayers and the disdain is almost always either some weird aversion to XML (such a trivial reason to choose a worser build system) and/or because the programmer never took the time to understand the rather simple Maven runtime semantics and architecture.

A lot of people on the Java side have seen what being able to script your build turns into with Gradle. They've also don't want to learn Scala to do their build.

Ant worked well because it was extremely _explicit_: You had to say what you wanted. This gave it a lot of flexibility. Unlike some other tools, you aren't running in front of a train trying to get it to stop and let you on. It doesn't go anywhere or do anything until you say so. The cost was pretty much zero defaults and a good bit of boilerplate.

I think a lot of people expected this from Gradle because the idea of "build as programming" seemed like it would give that stop-the-train-let-me-on-already ability. I don't know that it really worked out that way. Maven is all about running devs over, but it's faster than Gradle, which tries to start a daemon just like SBT.

Anyhow... this bld thing looks interesting, thanks...

> These opinions are all valid, but only if they don't discount the validity of other strategies.

I strongly agree with this as a general principle in nearly all technical discussions.

But also, if the discussion starts with declaring something is better than everything else (as the title here), then there's really no salvaging it anymore.

> There are cases where build performance is critical, *and others where it's not.*

I'm curious about those.

Which works fine.....until it doesn't. Many non-trivial builds require custom logic, and trying to do that in maven was painful the last time I tried it.

> maven is just a configuration file

Even better, Maven "POMs" are written in a common, standard format (XML); so we can transform and manipulate it using off-the-shelf tools, if we really want to. I've found this useful e.g. in pre-commit hooks (tidy the formatting, checking/linting, etc.); in Nix builds (e.g. removing the version number, so it doesn't affect the hash and avoids spurious rebuilds); etc. That was a nice bonus when I switched some projects from SBT to Maven (due to SBT being wildly unreproducible).

I hate wrangling with configuration to make an amalgamation of plugins do what's expected in the expected order for my build; Gradle is just code and a DSL

You can write bad code in any language. Don’t ask me how I know :)

Yeah, hard to see how better this is than Gradle. If anything, it's worse by the mere fact this is Scala, but it's really so incredibly verbose to accomplish basic tasks such as upload to Sonatype.

JVM build tools have to do much more than just dependency management because of how the JVM works (e.g. packaging resources). It's not really comparable.

When has build time been an issue though? Running tests have taken the most time by far on every project I’ve ever worked on.

Bazel is just such a nightmare for me. It's amazing when someone understands it really well and can set things up. But for anything short of that, being on the hook to fix or debug things makes it a nightmare. That and trying to port anything over from sbt, like scalafix for instance, to bazel is a pain.

Also too, bazel has this issue of googleability? like I feel like I can take any build issue I've run into in sbt and find the solution and an example by just searching, but with Bazel, anything outside of the happy path is a recipe for pain