Hacker News Reader

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.

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...

> 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).

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.

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.

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.

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.

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).

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...

The main idea is to use the language to create another language layer, better suited to the task at hand.

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.

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.

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.

> 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.

> > 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.

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)

> 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.

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.

>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.

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.

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.

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.

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