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.

Author here. The neat thing is, with Mill you don't need any of those plugins because it's all built in (except for the license plugin I believe), and is tested/documented together in the main codebase. So it generally all works pretty well together and you shouldn't have issues.

Mill generally is able to replace a lot of first-party/third-party extensions with builtin functionality: beyond the plugins above, it also subsumes autoformatting plugins, linting plugins, external tools like sdkman/jenv, and so on. Thus when using Mill you often don't even think about "what plugins I need", because the bulk of common use cases are provided out of the box, and you can instead focus on your actual project and application code

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.

> Gradle is too ant-like

Kinda fascinated by this opinion, I was never a fan of either ant or maven, but I find Gradle perfectly fine for Kotlin, maybe there is either a little difference between Java/Kotlin, or I was mostly spending my time with "old" maven setups, or something completely different. I'm not saying ant and maven have a lot in common, just that I didn't like either.

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).

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 think you can make it 10 years. It is super robust. It just works for java stuff.

If you are doing Kotlin and especially Kotlin multi platform, Gradle with the kotlin dialect (not Groovy) is the default choice in the ecosystem. That might change soon as Jetbrains has been working on their own build tool (amper). Maven is an afterthought in the Kotlin world. You can obviously use it with things like Spring. But it's not a well supported, or well documented thing in many Kotlin projects, the Kotlin documentation, or any of the Kotlin build tooling that Jetbrains supports.

Just look at all your Kotlin library dependencies on Github and do a little surveil of what those use. There's a clear picture that emerges of what is common and what is a distinct outlier. Maven is clearly not a mainstream choice in many Kotlin projects on Github. There are a few maven projects. But mostly it's all gradle. And most of that is using the kotlin DSL dialect of that at this point.

Unlike Maven, Gradle has seen a lot of active development adding many similar features that are being advertised for Mill. For example the configuration cache is now default in the upcoming major version (9.0 release candidates are out). And it does make a big difference if you use that. Although cache coherence issues are obviously a potential problem here.

I don't know Mill and it flew a bit under the radar for me. So I won't say anything negative about it. But, I'm not that optimistic I can use it on my multi platform kotlin projects. That's just because a lot of Kotlin is developed in lockstep with the compiler and gradle plugins that it uses, which are very gradle centric. For example, Kotlin multiplatform builds with its own gradle plugin that ships with each Kotlin release. And replacing that with something else is not really that trivial on the type of projects I do.

A lot of Kotlin multi platform needs quite complicated build steps to interact with build tooling for different platforms (llvm, xcode, wasm, jvm, node, etc.). Most of that stuff is being developed by Jetbrains. They don't spend a lot of time on thinking about or supporting maven.

I'm not a Gradle fan boy BTW. I've used Maven and Ant before that. I really dislike the Groovy legacy in Gradle. It makes everything so complicated and convoluted. And that leaks through in the Kotlin DSL for gradle. And clearly Jetbrains is also not that happy with gradle because they are working on Amper.

But it works and the performance work they've been doing in the Kotlin build tools and Gradle is really paying off. I've seen quite massive build speed improvements over the last few years for the same projects on the same hardware.

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...

Re: ant, make that two of us.

I use Gradle these days since IntelliJ doesn't work well with ant; but when I want to precisely control how a build is done and produce exactly the build products I want, I use ant. It's stable, it's well-documented, and I never need to guess what it's doing because it's doing what I told it to do.

I like the idea of an opinionated build tool; but I'm not happy with any of the ones I've tried.

> 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.

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.

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

Author here. What most people don't realize is that "I hate programming my build." is a symptom of your existing build tools making programming your build dangerous and risky endeavor.

For example, in Maven you typically extend your build in Bash scripts + maven-exec-plugin, Ant script + maven-antrun-plugin, or custom Maven plugins entirely. None of these are "nice" programming environments, with proper IDE support, typechecking, introspectability, and so on. Writing lots of logic in Bash or Ant is risky, so you would be right to minimize writing code in it

Similarly, in Gradle you extend your build in Groovy/Kotlin, but it's a kind of "weird" Groovy/Kotlin unlike anything you'd write in application code. For example, your IDE support in Gradle-Kotlin is much worse than what you get in normal-Kotlin. Despite Gradle-Kotlin being the same language and same IDE, it's a much worse experience writing it, it's much easier to make mistakes, and so you are right to minimize the code you write in it.

In Mill, the build scripts are in Scala, but that's not the important part. The important part is you write normal code using classes, methods, and overrides. IDEs are very good at navigating classes, methods and overrides, and developers are very familiar with working with classes, methods, and overrides. And so build code in Mill feels as comfortable as your application code in Java/Scala/Kotlin: same quality of IDE experience, same typechecking, even can use the same Java third-party libraries (if you wish).

So it's understandable you hate programming your build. In Maven or Gradle or SBT, I'd hate programming my build as well. What Mill offers is that you can program your build where necessary without the hate that comes with doing so in other build tools!

> I eschew frameworks in this custom build tool, because the build code should look conventional for whatever language it's written in.

That's really the case with Mill as well, at a deeper more-meaningful level. Mill builds are all built around objects, classes, methods, and overrides.

Maven is XML. Do you write large codebases in XML? Gradle is Groovy/Kotlin, but it's an odd Groovy/Kotlin dialect or DSL that looks totally unlike application codebases, and your IDE is unable to understand and navigate effectively.

Mill is Scala, sure, but what's important is that it is architected around objects, classes, methods, and overrides. Those are the core abstractions when working with Mill, which are the same core abstractions as any Java/Scala/Kotlin application. Thus IDEs are able to navigate Mill builds, profilers like JProfiler or Yourkit can work on Mill builds, and humans who learned Java 101 in college are immediately familiar with the structure and fundamental abstractions of Mill.

I've seen this taken to extremes (eg Kubernetes deployment as Java code simply because the service is in Java) and it's... terrifying. It's justified in the pre-internet era, where learning two languages would require two trips to the library. These days, I really don't see why not using the better tool for whatever part of the job you're doing. It creates a mountain of complexity for no reason other than "I only want to touch language X"

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.

This is the first time I have heard of it.

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.

undefined

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.

Mill is in many ways trying to be `uv` for the JVM. 3-6x faster than the existing tools, bundling everything necessary builtin without plugin-hell, superior IDE support and toolability than existing tools. If you want a `uv` for Java, you should try out Mill!

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

My experience with Bazel (7 years rolling it out and maintaining it in a large company) is that it provides huge value for larger teams/codebases, but at a huge cost in complexity. e.g. the three I rollouts I was closest to each took ~2 person-decades to happen; might be easier now than it was in 2016/2017, but Bazel hasn't really gotten simpler over the years

Mill is intended to be much easier than Bazel. Most people would not use Bazel for a 1-person project, or even a 5-person project, and it only starts pencilling out once you have 50-100 engineers on the team. Mill in contrast works great for small projects and medium projects as well.

One way I'd look at it is that Mill works great for 1-500 person projects, while Bazel works great for 100-5000 person projects. There's some overlap in the middle, but fundamentally they target different kinds of users who have very different constraints and requirements

Please try out Mill! We have a lot of Maven/Gradle/SBT refugees in the community who are quite happy with Mill, so perhaps if you give it a try you'll find a build tool you can be happy with as well

That profiler is very powerful and used to analyze beasts like Android and Chromium. It's a pro, not a con.

https://ui.perfetto.dev