3 ms·
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.
by jpitz 1y 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.
- throwaway7783 1y agoOut of curiosity, what is non-trivial in this context?
- spullara 1y agoI have found that if it is hard to do in maven you probably shouldn't be doing it or there is a better way.
- ackfoobar 1y agoYeah. 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.
- lenkite 1y agoThat 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 1y agoAnd 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.
- switchbak 1y agoI 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.