3 ms·

Maven is great so long as there's a plugin to do what you need to do. If there isn't, it's quite possible that writing one will be simpler than trying to coax

Maven is great so long as there's a plugin to do what you need to do. If there isn't, it's quite possible that writing one will be simpler than trying to coax Maven into doing something unorthodox. For example, here's an old plugin I put together to allow easy publishing of a third-party artefact to a repository that didn't have a web interface for such things: https://github.com/andrewaylett/prepackaged https://github.com/andrewaylett/prepackaged It's old enough that the infrastructure I set up around it has bit-rotted -- I've just pushed a clone to GitHub to share here :). I'd hope using modern language features would make it easier still.

jpgvm 6y ago
Yeah this remains Gradles main advantage. You can author inline code to do interesting things or even full plugins by taking advantage of the buildSrc functionality.
- lmm 6y ago
  It's the main reason people use Grade but it's a trap. A build definition that allows people to inline arbitrary snippets of code anywhere will always end up as unmaintainable unless you have very strict rules about what kind of code is allowed where - and once you have those rules you end up with something that's no more flexible than Maven.
  - jpgvm 6y ago
    I somewhat agree. I feel like when I am trying to get some more complex build tooling worked out being able to prototype with inline tasks before developing a plugin is a big win. Doing such prototyping in Maven is quite arduous in comparison.
  - andrewaylett 6y ago
    Strong agree. The thing about Maven is that it requires us to build a project model, then it executes the model. That means it's possible to reason about what will happen based off the completed model. It doesn't matter whether the model is encoded in XML or generated in code: the important bit is that we (and our tooling) can inspect the model. Gradle _almost_ does the same, but it allows execution of arbitrary code in too many places -- like with parsing Perl, we can't discover the model without also executing it. Hence the trap.
- ivanche 6y ago
  Writing inline code (tasks) into build scripts is not recommended and, in the words of Cedric Champeau (former Grrovy committer and Gradle Inc. employee): "I repeat, nobody should every inline build logic in a build script. Nobody." [1] [1] https://melix.github.io/blog/2021/01/the-problem-with-gradle.html https://melix.github.io/blog/2021/01/the-problem-with-gradle...

jpgvm 6y ago

Yeah this remains Gradles main advantage. You can author inline code to do interesting things or even full plugins by taking advantage of the buildSrc functionality.

lmm 6y ago
It's the main reason people use Grade but it's a trap. A build definition that allows people to inline arbitrary snippets of code anywhere will always end up as unmaintainable unless you have very strict rules about what kind of code is allowed where - and once you have those rules you end up with something that's no more flexible than Maven.
- jpgvm 6y ago
  I somewhat agree. I feel like when I am trying to get some more complex build tooling worked out being able to prototype with inline tasks before developing a plugin is a big win. Doing such prototyping in Maven is quite arduous in comparison.
- andrewaylett 6y ago
  Strong agree. The thing about Maven is that it requires us to build a project model, then it executes the model. That means it's possible to reason about what will happen based off the completed model. It doesn't matter whether the model is encoded in XML or generated in code: the important bit is that we (and our tooling) can inspect the model. Gradle _almost_ does the same, but it allows execution of arbitrary code in too many places -- like with parsing Perl, we can't discover the model without also executing it. Hence the trap.
ivanche 6y ago
Writing inline code (tasks) into build scripts is not recommended and, in the words of Cedric Champeau (former Grrovy committer and Gradle Inc. employee): "I repeat, nobody should every inline build logic in a build script. Nobody." [1] [1] https://melix.github.io/blog/2021/01/the-problem-with-gradle.html https://melix.github.io/blog/2021/01/the-problem-with-gradle...