top | item 44584532

(no title)

jpitz | 7 months ago

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.

discuss

order

ackfoobar|7 months ago

Yeah. It's Greenspun's tenth rule.

If you have any complexity, programming against a good abstraction (Gradle is not good good, but decent) beats finding the magical incantation of configuration to get the tool to do what you want.

switchbak|7 months ago

I think folks just get used to Maven-induced constraints (this applies to SBT, Bazel, others too). When you free yourself from that you realize: builds just aren't all that hard, it's often the tooling that becomes a real limitation.

Of course, sometimes the limitations are good: preventing you from doing "the wrong thing", or encouraging cacheability, etc. But as with any abstraction layer - getting a model that fits across so many disparate use cases can be very challenging.

spullara|7 months ago

I have found that if it is hard to do in maven you probably shouldn't be doing it or there is a better way.

lenkite|7 months ago

That is why maven offers a plugin model for your custom logic that can be written in Java/Kotlin and a well defined lifecycle model where you can configure your plugin declaratively.

You can also download custom CLI tools and invoke them as part of a well-defined build lifecycle.

gf000|7 months ago

And then fail to do proper incremental builds, leaving you with no choice but a faulty build or clean installing on every occasion.

At the very least, I would move to Gradle which does have proper knowledge of your build graph. But Mill is also a good choice and fills the same niche, with the added benefit that imperative-looking ordinary scala code will simply become a parallelizable, cacheable build graph.

throwaway7783|7 months ago

Out of curiosity, what is non-trivial in this context?