[deepsun]

I feel like Gradle is only relevant for Android. All other projects are fine with Maven (and I like a lot that Maven doesn't allow to code in the build config, any complex logic should be extracted to a custom build plugin, using real code. I just have PTSD after some build.gradle monstrosities).

[gf000]

It's just that Maven doesn't have a good core abstraction and it is not a reliable build system. Like even with base plugins, let alone with additional ones you can't be sure that a build actually picked up every change, you often have to do a double take and do a clean install instead to get some stale files cleared. This should never happen in a build tool and every other feature is secondary to this error.

That's why I defaulted to Gradle, which has its own idiocities (like tending to break the syntax on every second major version, but it's much better with the kotlin DSL), which at least 100% sound.

For more experimental/hobby projects I choose mill though.

[deepsun]

But it's IDE who picks up every change, not Maven. God forbid you run 'mvn install' for all modules on every line change while developing, that's IDEs job. Maven config just tells IDE locations and dependencies.

For release build you do want to clean up the space in CI/CD anyway.

Not sure what you mean by "doesn't have a good core abstraction". For example, Linux famously doesn't have a good core abstraction (aka "monolithic kernel").

[gf000]

It's not a good core abstraction for a build tool to not be able to do proper iterative builds. And thus it's not a good model for IDEs neither, while with Gradle it never gets out of sync, with Maven it can easily happen that some edits don't "show up" in behavior.