4 ms·

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

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.
      - oweiler 9y ago
        Gradle plugins work exactly the same. The only difference is that you define a task of the type a plugin exposes, configure it via its API and define dependencies to other tasks. Not very different from configuring a Maven plugin.
    - kelnos 9y ago
      Right. And in my opinion that's a strength. I don't want it to be trivially easy to do something custom. I want the person who thinks they need to do something custom to think long and hard about it, and really pause to consider they might be approaching the build issue in the wrong way before plowing ahead with some custom, (often) unmaintainable code. Having guardrails in your build system that are difficult to jump over is a good thing.
- tenken 9y ago
  Can you supply an online tutorial of this approach using Gradle? ... I'm not sure what to google to find it myself (I don't use Gradle, but it sounds powerful).
  - lmilcin 9y ago
    The concept of DSL is quite popular and well known. It can be effectively implemented in almost every language, but some languages are better suited to DSLs than others and allow hiding the underlying language structures (this is so called "syntactic sugar"). Here is a small example I just googled: http://mrhaki.blogspot.com/2013/05/gradle-goodness-extending-dsl.html http://mrhaki.blogspot.com/2013/05/gradle-goodness-extending... The main idea is to use the language to create another language layer, better suited to the task at hand.
    - tenken 9y ago
      Thanks, no idea grandle has 1st class support for creating DSLs and I overlooked the 1 keyword you had in your reply -- my bad. In general I am familiar with dsl's. Appreciate the feedback.
einrealist 9y ago
It took a while for me to fully understand Maven. I tried to look at plugins to understand it, but I struggled. My experience with Gradle was different. After reading the source of a few plugins, I understood that Gradle at its core is just tasks + variables / objects that add syntactic sugar to the DSL. Today, I find Gradle more accessible and flexible than Maven. Its a bit unfortunate that a lot of Gradle tutorials start with the syntactic sugar.
- chopin 9y ago
  I understood much of Maven better after writing a Maven plugin. After doing the first I lost my hesitance to write one if needed. I can only recommend that. Until then I had pretty much a hate relationship with Maven. Mostly tests failed due to improper excluded transitive dependencies. Once writing your own plugin you understand depenendency management and class-loading much better.
xienze 9y ago
> 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 That, and it sounds like the parent doesn’t understand POM inheritance and archetypes.
kelnos 9y ago
> > 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. Agreed. Every time I see a build system that lets you write arbitrary code, I shy away from it. Builds should be standardized, not a mess of custom code. Maven lets you write plugins for the case when you need to do something truly custom, but in my experience that's vanishingly rare.
- usrusr 9y ago
  I think the difference between arbitrary code in buildfiles and an obscene zoo of plugins running arbitrary code is rather small in terms of actually understanding the build. My takeaway from using both maven and gradle is that I would really love to have a build system with emphasis on allowing custom arbitrary code, but only within guiderails that force them into a shape that is easily factored into a plugin if you layer decide to do so. Maybe even with a defined reverse path for unboxing existing plugins back into their inline form (for when you absolutely need a fix/unexpected customization, but can't commit to fully maintaining the plugin)
  - kelnos 9y ago
    > I think the difference between arbitrary code in buildfiles and an obscene zoo of plugins running arbitrary code is rather small in terms of actually understanding the build. Completely disagree. Off-the-shelf plugins behave in defined and documented ways, and understanding a build that uses a particular plugin just means reading that plugin's documentation. When you allow arbitrary code in the build file, it means you have to puzzle out what the author was trying to do, for each and every case where you see unusual arbitrary code. You also get into situations where there's more than one way to accomplish many tasks, so you have to learn all of them instead of relying on a standard built-in method. Sure, any random maven user in your organization can write a plugin to add undocumented behavior, but I rarely see that happen in practice. Even though writing a maven plugin actually is pretty easy, there's an implied barrier both in setting up a plugin project and writing it, as well as publishing it in a way that that a consuming build can use it. So you end up with it being rare to write a custom plugin. There are very few things you can't do with off-the-shelf maven plugins, and arguably I'd rather be restricted and be unable to do some things than have to deal with the mess that arbitrary code creates. I've seen it time and time again with people who try to introduce sbt into my org, and it makes me want to scream.

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.
    - oweiler 9y ago
      Gradle plugins work exactly the same. The only difference is that you define a task of the type a plugin exposes, configure it via its API and define dependencies to other tasks. Not very different from configuring a Maven plugin.
  - kelnos 9y ago
    Right. And in my opinion that's a strength. I don't want it to be trivially easy to do something custom. I want the person who thinks they need to do something custom to think long and hard about it, and really pause to consider they might be approaching the build issue in the wrong way before plowing ahead with some custom, (often) unmaintainable code. Having guardrails in your build system that are difficult to jump over is a good thing.
tenken 9y ago
Can you supply an online tutorial of this approach using Gradle? ... I'm not sure what to google to find it myself (I don't use Gradle, but it sounds powerful).
- lmilcin 9y ago
  The concept of DSL is quite popular and well known. It can be effectively implemented in almost every language, but some languages are better suited to DSLs than others and allow hiding the underlying language structures (this is so called "syntactic sugar"). Here is a small example I just googled: http://mrhaki.blogspot.com/2013/05/gradle-goodness-extending-dsl.html http://mrhaki.blogspot.com/2013/05/gradle-goodness-extending... The main idea is to use the language to create another language layer, better suited to the task at hand.
  - tenken 9y ago
    Thanks, no idea grandle has 1st class support for creating DSLs and I overlooked the 1 keyword you had in your reply -- my bad. In general I am familiar with dsl's. Appreciate the feedback.

einrealist 9y ago

It took a while for me to fully understand Maven. I tried to look at plugins to understand it, but I struggled. My experience with Gradle was different. After reading the source of a few plugins, I understood that Gradle at its core is just tasks + variables / objects that add syntactic sugar to the DSL. Today, I find Gradle more accessible and flexible than Maven. Its a bit unfortunate that a lot of Gradle tutorials start with the syntactic sugar.

chopin 9y ago
I understood much of Maven better after writing a Maven plugin. After doing the first I lost my hesitance to write one if needed. I can only recommend that. Until then I had pretty much a hate relationship with Maven. Mostly tests failed due to improper excluded transitive dependencies. Once writing your own plugin you understand depenendency management and class-loading much better.

xienze 9y ago

> 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 That, and it sounds like the parent doesn’t understand POM inheritance and archetypes.

kelnos 9y ago

> > 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. Agreed. Every time I see a build system that lets you write arbitrary code, I shy away from it. Builds should be standardized, not a mess of custom code. Maven lets you write plugins for the case when you need to do something truly custom, but in my experience that's vanishingly rare.

usrusr 9y ago
I think the difference between arbitrary code in buildfiles and an obscene zoo of plugins running arbitrary code is rather small in terms of actually understanding the build. My takeaway from using both maven and gradle is that I would really love to have a build system with emphasis on allowing custom arbitrary code, but only within guiderails that force them into a shape that is easily factored into a plugin if you layer decide to do so. Maybe even with a defined reverse path for unboxing existing plugins back into their inline form (for when you absolutely need a fix/unexpected customization, but can't commit to fully maintaining the plugin)
- kelnos 9y ago
  > I think the difference between arbitrary code in buildfiles and an obscene zoo of plugins running arbitrary code is rather small in terms of actually understanding the build. Completely disagree. Off-the-shelf plugins behave in defined and documented ways, and understanding a build that uses a particular plugin just means reading that plugin's documentation. When you allow arbitrary code in the build file, it means you have to puzzle out what the author was trying to do, for each and every case where you see unusual arbitrary code. You also get into situations where there's more than one way to accomplish many tasks, so you have to learn all of them instead of relying on a standard built-in method. Sure, any random maven user in your organization can write a plugin to add undocumented behavior, but I rarely see that happen in practice. Even though writing a maven plugin actually is pretty easy, there's an implied barrier both in setting up a plugin project and writing it, as well as publishing it in a way that that a consuming build can use it. So you end up with it being rare to write a custom plugin. There are very few things you can't do with off-the-shelf maven plugins, and arguably I'd rather be restricted and be unable to do some things than have to deal with the mess that arbitrary code creates. I've seen it time and time again with people who try to introduce sbt into my org, and it makes me want to scream.