4 ms·

Does anyone have a good resource for learning a systematic way to do dependency management for large codebases? Seems like every time it comes up in gradle or m

Does anyone have a good resource for learning a systematic way to do dependency management for large codebases? Seems like every time it comes up in gradle or maven I have to trial-and-error my way out of resolution hell.

bitcharmer 6y ago
Just use Maven. Could you point out what exactly in Maven makes it hard to use for you?
- jpgvm 6y ago
  Maven makes doing things off the beaten path very hard. This can be good as most Maven builds won't surprise anyone but if you often find yourself doing such things (mixed language projects, custom code generation steps, etc) then Maven will always be harder to use and you will have to spend more time writing plugins vs Gradle. Maven is great when all you want to do is build a simple Java project and publish it, when you step outside of that it becomes much more painful.
  - andrewaylett 6y ago
    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...

bitcharmer 6y ago

Just use Maven. Could you point out what exactly in Maven makes it hard to use for you?

jpgvm 6y ago
Maven makes doing things off the beaten path very hard. This can be good as most Maven builds won't surprise anyone but if you often find yourself doing such things (mixed language projects, custom code generation steps, etc) then Maven will always be harder to use and you will have to spend more time writing plugins vs Gradle. Maven is great when all you want to do is build a simple Java project and publish it, when you step outside of that it becomes much more painful.
- andrewaylett 6y ago
  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...