6 ms·

I moved from Maven to Gradle about two years ago and I am not going to look back. I understand the arguments made in article and I am the Gradle ninja in my pr

I moved from Maven to Gradle about two years ago and I am not going to look back. I understand the arguments made in article and I am the Gradle ninja in my project so I may have subjective view on the whole topic. My points: - Maven requires a lot of boilerplate for everything. Copy-paste. I need to instruct everybody on what to copy, where to paste, and how to edit and what they should not touch under any circumstances. - Gradle... It's an environment for programmer! I just write a bunch of code in Kotlin so that all 100 projects have a bit of my custom DSL that suits the needs of our application. The code takes the DSL and does all the job behind the scenes and most developers don't need to understand it. They can, but they don't need to. This is how it is supposed to work -- in a large project people specialize and the application should be created in a way that will allow people to not have to understand everything. - Maven is strictly declarative. If you can't find a plugin you either dig up Ant or you have to write your own plugin. Not nice. - In Gradle I can have almost everything declarative but I have the freedom to drop this bit of logic where it is really needed. - Don't try to make it too complex just because you start using Gradle. Great power comes with great responsibility. If I wanted to change one thing in Gradle it would be for the Gradle project to focus on debugging. I really find it difficult to figure out why things fail even though I have almost 20 years of experience with various languages and a decade of very intimate experience with Java. Make it easier so that people are not put off.

bitcharmer 9y ago
I'm neither Maven nor Gradle ninja. Just a senior software developer with 15+ years of experience... > Maven requires a lot of boilerplate for everything. Copy-paste I think you may be doing it wrong. Maven supports declaring project-wide or module-wide entities and their attributes at every level. Duplication or copy-paste is a sign of not understanding Maven > Gradle... It's an environment for programmer To me this is a counter-argument. When I need to understand project configuration I expect structure, not behaviour. > If you can't find a plugin you either dig up Ant Been doing Java software engineering for many different projects in various industries on all scales and I only had that problem once or twice.
- lmilcin 9y ago
  It may be you are doing plain simple (can be large, but still simple) projects for which Maven is perfectly fine. Gradle is for when you require some more complicated behaviour in your project. For example in my current project the applications are packaged into completely custom and proprietary package that is then being used by the completely custom automation to be deployed to the infrastructure. I have created a DSL which allows people to specify rules concerning how their projects are supposed to be treated when they are being included in one of these large packages. I have also placed some extension points that allow people to attach their automation. The extension points are there so that automation tasks that are specific to projects don't have to all live in a single gigantic automation script (out of my control) but can be nicely separated for each project. Mind that we are not putting automation in the build script. The build script is there to organize the process not to be the place where you put your commands. Now, I don't even want to start thinking how I would do this with Maven... probably would dump this work on somebody else...
  - kelnos 9y ago
    > For example in my current project the applications are packaged into completely custom and proprietary package that is then being used by the completely custom automation to be deployed to the infrastructure. If you really need something insanely custom, you can just write a maven plugin (it's actually really easy to do so).
    - orbitur 9y ago
      Not as easy as using gradle. I've written a couple maven plugins in my time, and I'm so very glad we have gradle now.
      - chii 9y ago
        Maven plugins still have lots of structure to obey, but you can treat the plugin as a black box very easily. Other people dont need to understand the innards to compose the plugin with other plugins. I'd be hard-pressed to see how you can do that with gradle.
kovrik 9y ago
For me the main difference between Maven and Gradle is the way I read them. Maven is declarative. Yes, it has some boilerplate, it may not look nice (I'm not a big fan of XML), but the main advantage for me is that I can read it easily and understand what it does. Because it just declares tasks. Similar to any other XML file or JSON or .properties. You just read it. Reading Gradle, on the other hand, is more like reading a program. You can't just read it, you have to interpret it, you need to put effort in order to understand what this program does. Yes, Gradle may be more flexible and less boilerplate, but personally I don't want to have another program (in another language) to just build my project.
moocowtruck 9y ago
Honestly I can't believe people are arguing for maven over gradle... switched an entire very large org, all our java projects to gradle from various things over the last few years...everyone could not be happier. So much simpler, I only hear happiness from teams. Still run by a maven dumpster fire here and there though for the holdouts
chapill 9y ago
>Gradle... It's an environment for programmer! >Maven...you have to write your own plugin. Not nice. >If I wanted to change one thing in Gradle it would be for the Gradle project to focus on debugging You've just explained why I have no interest in Gradle. You're writing one off, undocumented, anonymous plugins, in a weird domain specific language, with debugging tools that aren't very good. Worse, when the Gradle guru decides to leave the company for greener pastures, everyone else is left with a mess trying to figure out WTH that person was doing in all the build files.
- orbitur 9y ago
  This sounds like a process problem, not a gradle problem. I don't think there's inherent readability to maven, and I'd love to share my previous employer's pom files with you.
- lmilcin 9y ago
  Yeah, especially code like that: artifactory { publish { repository { repoKey = version.endsWith('-SNAPSHOT') ? 'libs-snapshot-local' : 'libs-release-local' } } } In Gradle, this is immediately understandable to everybody. You can't do this in Maven without plugin support or some very protracted constructs. Sprinkling those small bits makes the Gradle useful. We are not talking about making a beast of a build system, just provide you with an ability to solve your problems. You may not want or like to learn another tool and that's fine. But don't think that just because you don't see the reason it means its not useful for other people.
  - chapill 9y ago
    You're now contradicting yourself: >I really find it difficult to figure out why things fail even though I have almost 20 years of experience >In Gradle, this is immediately understandable to everybody You pulled an easy example to defend Gradle for the exact problem you just complained about. >You may not want or like to learn another tool and that's fine. It's not about like or want, it's about having the wisdom to recognize a poor solution before investing time in adopting it. OP fell for the hype. Maven works fine for me, thanks.

bitcharmer 9y ago

I'm neither Maven nor Gradle ninja. Just a senior software developer with 15+ years of experience... > Maven requires a lot of boilerplate for everything. Copy-paste I think you may be doing it wrong. Maven supports declaring project-wide or module-wide entities and their attributes at every level. Duplication or copy-paste is a sign of not understanding Maven > Gradle... It's an environment for programmer To me this is a counter-argument. When I need to understand project configuration I expect structure, not behaviour. > If you can't find a plugin you either dig up Ant Been doing Java software engineering for many different projects in various industries on all scales and I only had that problem once or twice.

lmilcin 9y ago
It may be you are doing plain simple (can be large, but still simple) projects for which Maven is perfectly fine. Gradle is for when you require some more complicated behaviour in your project. For example in my current project the applications are packaged into completely custom and proprietary package that is then being used by the completely custom automation to be deployed to the infrastructure. I have created a DSL which allows people to specify rules concerning how their projects are supposed to be treated when they are being included in one of these large packages. I have also placed some extension points that allow people to attach their automation. The extension points are there so that automation tasks that are specific to projects don't have to all live in a single gigantic automation script (out of my control) but can be nicely separated for each project. Mind that we are not putting automation in the build script. The build script is there to organize the process not to be the place where you put your commands. Now, I don't even want to start thinking how I would do this with Maven... probably would dump this work on somebody else...
- kelnos 9y ago
  > For example in my current project the applications are packaged into completely custom and proprietary package that is then being used by the completely custom automation to be deployed to the infrastructure. If you really need something insanely custom, you can just write a maven plugin (it's actually really easy to do so).
  - orbitur 9y ago
    Not as easy as using gradle. I've written a couple maven plugins in my time, and I'm so very glad we have gradle now.
    - chii 9y ago
      Maven plugins still have lots of structure to obey, but you can treat the plugin as a black box very easily. Other people dont need to understand the innards to compose the plugin with other plugins. I'd be hard-pressed to see how you can do that with gradle.

kovrik 9y ago

For me the main difference between Maven and Gradle is the way I read them. Maven is declarative. Yes, it has some boilerplate, it may not look nice (I'm not a big fan of XML), but the main advantage for me is that I can read it easily and understand what it does. Because it just declares tasks. Similar to any other XML file or JSON or .properties. You just read it. Reading Gradle, on the other hand, is more like reading a program. You can't just read it, you have to interpret it, you need to put effort in order to understand what this program does. Yes, Gradle may be more flexible and less boilerplate, but personally I don't want to have another program (in another language) to just build my project.

moocowtruck 9y ago

Honestly I can't believe people are arguing for maven over gradle... switched an entire very large org, all our java projects to gradle from various things over the last few years...everyone could not be happier. So much simpler, I only hear happiness from teams. Still run by a maven dumpster fire here and there though for the holdouts

chapill 9y ago

>Gradle... It's an environment for programmer! >Maven...you have to write your own plugin. Not nice. >If I wanted to change one thing in Gradle it would be for the Gradle project to focus on debugging You've just explained why I have no interest in Gradle. You're writing one off, undocumented, anonymous plugins, in a weird domain specific language, with debugging tools that aren't very good. Worse, when the Gradle guru decides to leave the company for greener pastures, everyone else is left with a mess trying to figure out WTH that person was doing in all the build files.

orbitur 9y ago
This sounds like a process problem, not a gradle problem. I don't think there's inherent readability to maven, and I'd love to share my previous employer's pom files with you.
lmilcin 9y ago
Yeah, especially code like that: artifactory { publish { repository { repoKey = version.endsWith('-SNAPSHOT') ? 'libs-snapshot-local' : 'libs-release-local' } } } In Gradle, this is immediately understandable to everybody. You can't do this in Maven without plugin support or some very protracted constructs. Sprinkling those small bits makes the Gradle useful. We are not talking about making a beast of a build system, just provide you with an ability to solve your problems. You may not want or like to learn another tool and that's fine. But don't think that just because you don't see the reason it means its not useful for other people.
- chapill 9y ago
  You're now contradicting yourself: >I really find it difficult to figure out why things fail even though I have almost 20 years of experience >In Gradle, this is immediately understandable to everybody You pulled an easy example to defend Gradle for the exact problem you just complained about. >You may not want or like to learn another tool and that's fine. It's not about like or want, it's about having the wisdom to recognize a poor solution before investing time in adopting it. OP fell for the hype. Maven works fine for me, thanks.