I wonder what people use/need apart from the usual stuff in Maven nowadays.
In the last 5 years, I didn't need anything more than:
- resource plugin
- compiler plugin
- jar plugin (jars, test jars, javadoc jars)
- surefire/failsafe
- shade plugin for repackaging to avoid classpath hell
- assemble plugin
- license plugin
Most of the issues I had were with the shade/assemble/license plugins.
I consider myself a Maven power-user and like the tool compared to others (Gradle is too ant-like, resulting in non-standard builds, sbt is just a torture tool).
With time, I concluded that the simpler it is, the better.
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.
IMO there should be one build system for each language and it should be good at the basics, and if you need more then you should write your own (minimal-dependency) build script in the same language as the code you're building, and in that system you do things like generate build files for the big, complicated thing you're trying to build.
In Java terms, if you have a big complicated Java repo that requires lots of steps to build, you should have a separate Java project in there just for building the main repo. That separate Java project should be built and run with maven, and that separate project can do all kinds of fancy things, but ultimately it will be generating maven projects or calling maven with special command line parameters or something like that.
I even put the logic for CI in my build project like this. It makes everything reproducible and debuggable. How cool is it to be able to put a breakpoint in your build script? How about stepping through your CI code? Things are way simpler this way.
I eschew frameworks in this custom build tool, because the build code should look conventional for whatever language it's written in.
This is kinda funny. Generating a profile that is meant to be visualized with a web browser's built-in profiler, not even an HTML file. I guess if it's already built and works well ¯\_(ツ)_/¯
Not a lot of love for Mill in these comments. I'm interested in what it has to offer.
I find SBT just has a lot of unnecessary abstractions and complexity. It's so opaque that I'm sure I'm leaving a lot of performance on the table with hidden antipatterns. Mill seems to solve that by being 'boring' (in a good way). Being able to trace what's happening in my IDE would be lovely - and something I don't have in SBT or Maven either.
Now that we also have fast running native CLI tooling, I think it's worth another look over SBT.
Honestly, I'm getting tired of the endless parade of "better" build tools. Maven works fine for most of what I do, even if it's occasionally painful. Gradle is... well, Gradle has its moments.
That said, Mill's performance claims sound interesting. If it really can cut build times by 3-6x, that's really amazing. I've wasted too much time in my life waiting for builds, especially on larger projects.
The Scala thing is a bit of a turn-off though. I get that you don't need to write Scala yourself, but now I'm dragging in the Scala ecosystem just to build my Java project? Feels heavy.
The IDE integration sounds nice in theory - being able to actually navigate and understand your build in IntelliJ would be pretty sweet.
Still not sure the switching costs are worth it unless you're really hitting Maven/Gradle pain points. But if I was starting a new project from scratch, might be worth a look.
Is it bootstrappable? I mean really bootstrappable, not "the bootstrap script will download a binary from some server". This is where both Maven and Gradle fail (at least the last time I checked). Kotlin and Scala also have the problem that their compilers themselves are not bootstrappable either.
Reading these comments I'm always amused by how different people/teams have radically different needs & preferences, and how other people seem to be dismissive of those. "I don't need anything more than maven", "maven is too slow", "if it's not bootstrappable I don't want it", "there should only be one ultimate build tool", "I hate programming my build", etc.
These opinions are all valid, but only if they don't discount the validity of other strategies. There is no universal law of optimal build practices. There are cases where build performance is critical, and others where it's not. There are cases where configurability is important, and there are cases where it's not. Etc.
Personally, I love having a programmable build in plain Java, which is why I enjoy bld [1] these days. I'm probably the only person you'll ever meet who actually enjoyed using ant, so you're welcome to take my opinion with as much salt as you need to digest that.
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.
21 comments
[ 3.3 ms ] story [ 41.5 ms ] threadMill as a direct style build tool - https://news.ycombinator.com/item?id=43943792 - May 2025 (9 comments)
Why does Mill use Scala? - https://news.ycombinator.com/item?id=42997496 - Feb 2025 (75 comments)
Mill: A fast JVM build tool for Java and Scala - https://news.ycombinator.com/item?id=41967734 - Oct 2024 (162 comments)
What's So Special About the Mill Scala Build Tool - https://news.ycombinator.com/item?id=38877882 - Jan 2024 (1 comment)
Mill: A Build Tool Based on Pure Functional Programming - https://news.ycombinator.com/item?id=25925107 - Jan 2021 (1 comment)
Mill: Better Scala Builds - https://news.ycombinator.com/item?id=16775545 - April 2018 (16 comments)
In the last 5 years, I didn't need anything more than:
- resource plugin - compiler plugin - jar plugin (jars, test jars, javadoc jars) - surefire/failsafe - shade plugin for repackaging to avoid classpath hell - assemble plugin - license plugin
Most of the issues I had were with the shade/assemble/license plugins.
I consider myself a Maven power-user and like the tool compared to others (Gradle is too ant-like, resulting in non-standard builds, sbt is just a torture tool).
With time, I concluded that the simpler it is, the better.
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.
In Java terms, if you have a big complicated Java repo that requires lots of steps to build, you should have a separate Java project in there just for building the main repo. That separate Java project should be built and run with maven, and that separate project can do all kinds of fancy things, but ultimately it will be generating maven projects or calling maven with special command line parameters or something like that.
I even put the logic for CI in my build project like this. It makes everything reproducible and debuggable. How cool is it to be able to put a breakpoint in your build script? How about stepping through your CI code? Things are way simpler this way.
I eschew frameworks in this custom build tool, because the build code should look conventional for whatever language it's written in.
You don't have to learn a separate language or some weird config.
This is kinda funny. Generating a profile that is meant to be visualized with a web browser's built-in profiler, not even an HTML file. I guess if it's already built and works well ¯\_(ツ)_/¯
I find SBT just has a lot of unnecessary abstractions and complexity. It's so opaque that I'm sure I'm leaving a lot of performance on the table with hidden antipatterns. Mill seems to solve that by being 'boring' (in a good way). Being able to trace what's happening in my IDE would be lovely - and something I don't have in SBT or Maven either.
Now that we also have fast running native CLI tooling, I think it's worth another look over SBT.
That said, Mill's performance claims sound interesting. If it really can cut build times by 3-6x, that's really amazing. I've wasted too much time in my life waiting for builds, especially on larger projects.
The Scala thing is a bit of a turn-off though. I get that you don't need to write Scala yourself, but now I'm dragging in the Scala ecosystem just to build my Java project? Feels heavy.
The IDE integration sounds nice in theory - being able to actually navigate and understand your build in IntelliJ would be pretty sweet.
Still not sure the switching costs are worth it unless you're really hitting Maven/Gradle pain points. But if I was starting a new project from scratch, might be worth a look.
These opinions are all valid, but only if they don't discount the validity of other strategies. There is no universal law of optimal build practices. There are cases where build performance is critical, and others where it's not. There are cases where configurability is important, and there are cases where it's not. Etc.
Personally, I love having a programmable build in plain Java, which is why I enjoy bld [1] these days. I'm probably the only person you'll ever meet who actually enjoyed using ant, so you're welcome to take my opinion with as much salt as you need to digest that.
[1] https://rife2.com/bld
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.
Can someone from Astral fix Java too, please?
It works well and I don't have huge dependencies.
I only use mail, db's, JSON and QR, so I can upload the dependencies into the repo and they haven changed for decades.