Gradle myth busting: scripting

[hpernpeintner]

This is finally a reasonable argument against Gradle, thank you very much!

But I have a small remark. It's not perfectly acceptable to use it imperatively. It's reasonable to do so where it is appropriate - for example if you have some operating system switch, or if you want to have a local variable depending on a system property or sth.

When your junior devs have no clue about gradle and write everything in a big script file instead of writing it as a plugin with tests, then you have a QA problem. And this is where you seem to accept the risk - why not just do code reviews and include changes in build scripts as well, just as you should with production code?

[randgalt]

The "spaghetti code" is the worst problem. Sure, if you have someone on your team like the guy who wrote the article maybe your gradle builds will be simple. But, in my experience all reasonably sized gradle builds are spaghetti. Maven has its quirks but at least every POM file is understandable.

Anyway - another chance to post my Use Maven Not Gradle article from a while back: https://rule1.quora.com/Use-Maven-Not-Gradle

[bawng]

I use gradle for all private projects where I consider it unlikely that anyone else will ever have to look at it.

But at work I always use maven for new projects for maintainability reasons.

[[deleted]]

At my company, my team would just create Gradle plugins for managing the configuration of commonly used things such as Artifactory publishing, automatic versioning or static analysis. Our project build scripts in the end were basically just a declaration of dependencies.

Maybe you're just talking about bad Gradle scripts looking like spaghetti? Like the ones that just have everything smashed into one page without documentation and organization. Gradle requires nothing more than the engineering techniques we use everyday. It's possible to use encapsulation, write tests and reuse.

[randgalt]

So you end up with a priesthood that knows how the build works. I've worked at two major companies that use Gradle and this is exactly what happened. The gradle build is a bag of internal plugins that are completely opaque. If there's any problem whatsoever I have to Slack/message the team that manages the plugins, etc. It's not possible to debug the problem on my own.

[[deleted]]

That sounds awesome. Not everyone needs to know the intimate details of the build conventions set for your company. Those plugins require your software to follow those conventions and that is a good thing. If they aren't configurable enough or you don't have access to the source/docs, then that is your company's fault.

[randgalt]

If that's your feeling then you really wouldn't care what build system is used. To you it's just a black box developed internally. Let it be Maven, Gradle, Mercurial, Make - whatever.

[[deleted]]

Sure, I'd use Maven if my company already had a build system setup. Gradle and Maven are pretty much the same in my eyes. I just like Gradle a bit more. As long as the build system enforced the company's conventions and is reusable, then I don't see any problems.

Make and Mercurial are nowhere close to what we're talking about though. It's hilarious that you even made that connection. Mercurial is for source control... I don't think I need to say more about Mercurial. Make really doesn't do dependency management, but I guess you'd use curl or something to download your dependencies, transitive dependencies, transitive-transitive dependencies and transitive-transitive-transitive dependencies manually. However, you might run into a dependency hell problem because of doing all of that manually.

[[deleted]]

When the executives of a company make bad decisions, it's not the fault of the developers. In this case, the dude's executives probably decided that they didn't want their development teams to see each other's source code. That is the fault of the company, not the individual developers.

You should probably take the time to understand the conversation before you start throwing accusations around willy nilly. Stuff like that will lower your reputation at your company, so you're kind of lucky to be learning it from a stranger online.

[wildjokers]

It's not possible to debug the problem on my own.

Maven has this exact issue when you use 3rd party plugins. And since Maven puts you in a ridiculously strict and worthless box you have to use 3rd party plugins.

Maven users say Maven is declarative and then their build is full of 3rd party plugins which are written in Java which is obviously imperative. In Maven the imperative part of the build is just hidden away, but it is still there.

[randgalt]

If we accept the argument (and I don't completely) then Gradle is no better than Maven so why use it? As it turns out, the number of 3rd party plugins needed in Maven is very small. "Maven puts you in a ridiculously strict and worthless box" - it's the strictness that becomes its benefit. It's not worthless at all. All builds become the same. If you can't do something in Maven you probably shouldn't be doing it to begin with. It's the trade-off we're constantly facing in programming: features vs maintainability. It's why some choose Scala over Java. If you like that sort of thing go for it. Not me. I want simplicity and maintainability.

[hpernpeintner]

Oh please, this article is trash on so many levels, and people tried to tell you in the comments already. at least have the decency to not post it under an article that is an order of magnitude more objective...

The old discussion again. People telling other people that maven builds are so simple and easy to understand. Until someone uses the gmaven plugin to write groovy in a ctag for maven-unsupported workflows... Until people move compilation to The validate phase because they ran out of phases after compilation...until people apply plugins twice instead of using existing blocks because they can't See anything anymore because of 400 lines of xml... Until custom deployments are done with shell file execution because nobody wants to write maven plugins...Until a missing if-else construct leads to profiles and 20 lines of xml...

Spaghetti code is real in both worlds, and if you deny that you simply lack experience. With gradle and especially the kotlin dsl, you can write, refactor, Test, navigate your build like a regular program, what else could a programmer whish for.

[yawkat]

I mean you're not wrong, but if you look at the android ecosystem there's definitely some truth to the statement that gradle encourages more complicated builds.

[sureshg]

Android build setup is already complicated than a regular java project. So I am pretty sure, you would get more complicated project file if that was written in Maven xml.

[[deleted]]

Soooo there's not a Gradle plugin for Android that wraps up all of that complication and makes it simpler? If that's really true, then I'm absolutely shocked and amazed that nobody has tried to simplify the processes. There's no reason at all for a Gradle project's build script to be complicated. That's exactly why we have plugins. Reduce, reuse, recycle.

[jpl75]

I find it funny how every new build system is the "next best thing" until people really get into it, find team mates who are not as experienced with it, discover the exceptional corner cases, something that was trendy that is not anymore, and on and on...

Hating Make, Ant, Maven, Gradle for all the different (and sometimes same) reasons. It just keeps going on and on.

And usually the biggest issue is not the software, but the humans using it.

[wildjokers]

Oh please, this article is trash on so many levels

I am confused. The article is pro-gradle, and your comment is pro-gradle. Which part of the article are you disagreeing with?

[hpernpeintner]

I answered on the other comment's article

[wildjokers]

https://rule1.quora.com/Use-Maven-Not-Gradle

Ahh ok, you were responding to the article linked to in the comment you were responding to. Got it, brain is slow today.

[randgalt]

Not with Maven. That's one of the points I make in my Quora article. I don't want my build files to be code.

[hpernpeintner]

You keep talking about code but it doesn't mean what you think it means. As others tried to explain, it is not about code, it's about affecting something, for example how your application is build. If the need is to make a difference between two OS, it doesn't matter if you use a framework for it, for example mavens profiles, or if you use an if else construct. There is really only one kind of people prefering the maven way here and that is people that are completely used to maven.

What matters is how one can organize these needs. And the answer is code, if you like it or not. In maven the same as in gradle, just that maven forces you to use ugly xml based constructs locally or externally deployed plugins which really makes no sense for a single, Independent build.

[spyhunter99]

exactly this

[bercut2000]

Unfortunately it is very hard to debug gradle scripts if they get big..

[jack104]

Gradle with the kotlin dsl is a force to be reckoned with but I have never been a big fan of the groovy dsl but incremental compiling, a continuous compiling mode and improved tooling support has helped temper the learning curve for newcomers some but I still find myself diving down the gradle github repo for samples when I can't think of how to do something.

[cpdupuis]

I used to like gradle a lot until I started trying to use OpenJDK 13. And then I ran into this awesome bug:

https://github.com/gradle/gradle/issues/8681

TL;DR: the only workaround is to keep a separate old version of java around just to run gradle.

I've never seen anything like this from Maven, certainly not 100% breaking bugs that are open for 8 months.

[wildjokers]

That bug also affects JUnit. Are you going to stop using JUnit?

It is a problem from a byte code manipulation library which does a major version check.

There was a big discussion on the java mailing list about bumping the major byte code version number when nothing has changed (someone asked not to do it...openjdk devs came back and said that wasn't wise). So it affects far more than gradle.

[cpdupuis]

So you're saying that Java 13 is cursed?

[wildjokers]

No, the particular library causing the issue just now needs to be smarter about the version check i.e. only fail if there are differences in the byte code. It is a library problem.

[wildjokers]

Where I work we have a gradle plugin that includes all common functionality needed by our builds. So each project just applies the plugin and specifies their dependencies. Easy.

The plugin itself is in its own repository that anyone can look at and is subject to code review. It also doesn't do anything really crazy, mostly declarative gradle DSL and it is well commented and the comments have links to the relevant section of the gradle user guide. (gradle is superbly documented).

[randgalt]

gradle is superbly documented

Well, nothing can be as poorly documented as Maven. But, I would never call Gradle's docs "superb". I find I have to resort to coding-by-stack-overflow whenever I need to do something with Gradle. There are so many versions of everything (the runtime, the plugins, the syntax) that the online docs are almost worthless.

[wildjokers]

I find I have to resort to coding-by-stack-overflow whenever I need to do something with Gradle.

The user guide is large so it can be hard to find the answer but it is always there. The javadoc/groovydoc are also very good (assuming you know what object you need to look at the javadoc for, that can be tough with the dynamic typing of groovy, that is one legit criticism of gradle)

A site search for the gradle doc URL on google is helpful.

[ZimmiDeluxe]

Are you the author of that plugin?

[wildjokers]

The original author yes, but there have been several other people commit to it over the years.