Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Moved Back from Gradle to Maven

blog.philipphauer.de

Post reply on HN
Print view View original

161–170 of 172 posts

Re: Why I Moved Back from Gradle to Maven

#161

Post by tenken »

lmilcin wrote: post #130
tenken wrote: post #106

Earlier quoted context omitted.

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 l…

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.

Re: Why I Moved Back from Gradle to Maven

#162

Post by flukus »

andrewaylett wrote: post #140
flukus wrote: post #92

Earlier quoted context omitted.

I think that's a fundamental flaw of IDE's, they don't integrate with your development environment ;) Something I just thought of but have yet to try, could we have a build script generate the project structure that an IDE can use and get the best of both worlds? Looking through my VS project files, 50% of it is stuff the make file would be doing, the other 50% is just a list of files and dependencies. So let's say w…

Both Maven and Gradle have plugins that will generate Eclipse and IntelliJ project files. But also, both Maven and Gradle work by first building up a model of what the build will look like, then executing it. Gradle is complicated by the fact that it's much easier to run custom code that modifies the build during the build (which is why I don't like it so much), but IDEs can still inspect the build model to work out…

> Both Maven and Gradle have plugins that will generate Eclipse and IntelliJ project files.

So does this work as I suggested? Can you do whatever you want in you're build script and output something usable for eclipse?

> But also, both Maven and Gradle work by first building up a model of what the build will look like, then executing it

Isn't that pretty much what make has always done? You define outputs and what dependencies are needed for those outputs and make will work out the path to get there.

Re: Why I Moved Back from Gradle to Maven

#163

Post by lmm »

zmmmmm wrote: post #160
lmm wrote: post #55

Earlier quoted context omitted.

I mean objectively it's not a bad language for its era, I just never found a compelling reason to use Gradle rather than something else. When I started out on the JVM I used Jython for scripting tasks since I already knew Python, and once I started using Scala I used that for, well, everything really. I don't want to get too deeply into language wars, but Java, Python and Scala all have "killer" features, things they…

> Whereas Gradle just felt like "it's a Python/Ruby/Perl-like language that runs on the JVM" - if there's something Gradle's actually the best at, their communication failed to convey it I assume you meant groovy there. But yes, I remember actually posting exactly that view on here several years ago! I felt that if I was going to learn a JVM language, why not invest that effort in something that was more generally ap…

> This seamless interoperabiity with Java/JVM is a fairly subtle selling point especially since every JVM language will say they do it. It's only when you try to use them in complex projects and see them fall down that you realise that groovy is the only language that is philosophically trying to be close to Java (I'm fairly keen to try Kotlin to see how that holds up on this count).

Interesting - can you say anything more concrete/specific? E.g. with Scala I've gradually drifted away from a Java-like style over the years, but I found it was very possible to write in a close-to-Java style (e.g. using the Java collections rather than Scala ones, using mutable vars and null and subclasses) when that was what I wanted.

Re: Why I Moved Back from Gradle to Maven

#164

Post by bonesss »

kovrik wrote: post #6
rhacker wrote: post #4

I spent a good 18 years in the Java coding stack. I adopted Maven when they just released version 2 and watched one of its evangelists talk at a JavaOne. Obviously now it's insane to think about a programming language that doesn't have a dependency manager (even C/C++ has Conan!). After a long time fighting between what I liked best between Maven or Gradle I realized that the only thing I really needed was the parts…

Honestly, I have the opposite opinion. I really don't like it when there are custom bash build scripts. And you have to figure out how they work and what they do. And how to pass additional parameters etc. If you use Maven for your project, then I expect that if I run `mvn clean install` then it will build the project. I think that is the whole point of standard build tools: that you can switch projects easily, run t…

I think FAKE (https://fake.build/), hits an amazing sweet spot for this: standardized, predictable, with no sacrifice of programming/platform power when dealing with builds.

Project to another, just run "build.fsx" with the desired target -- it will self-download necessary tools and packages -- and you'll get a straightforward standard build. If you want to see the logic, just open it up: build scripts are standard F# scripts

Because you're using first-class scripting you get full language power, full component and package management power, full abstraction power, aided by a set of utility methods and tools. At any point things get hairy you can wrap them into a lib, or a full program, with no domain impedance. It's standard code, as learnable as the rest of the F# proj, no voodoo, no black boxes.

Heck, you can also load your project and use its libraries during the build. I find myself often using FAKE components in my main solutions to take advantage of its interop and publishing...

Re: Why I Moved Back from Gradle to Maven

#165

Post by dcposch »

NovaX wrote: post #154
dcposch wrote: post #102

I’m surprised nobody has mentioned buck or bazel in this thread. At Addepar a few years ago, I transitioned a several-100-k LOC Java codebase from Gradle to buck. It was a fairly complex build including Jooq code gen. Build times became much faster and flaky CI issues went away. Today, I’d try Bazel— Buck only exists because ex-Google FB engineers had to recreate Googles amazing Blaze build system. Google has since r…

I would have used Bazel (or Buck) at Addepar instead of Gradle had either been released (I really loved Blaze). The transition from IDE-only to a standard process was painful, as you remember. I'd like to use Bazel (or even Buck) these days, but no bandwidth given other projects. I always felt modules were a mistake compared to a single large tree, which Bazel does elegantly. Sadly my familiarity with Gradle is much…

Oh hi! Hope things are well!

Not hating on the Gradle setup at all — it made sense at the time.

I also like the tree approach, it feels clean. Plus the hash cache to avoid rebuilding things when nothing’s changed—faster and more robust than tools that use mod time.

I’m going to try Bazel soon at Dynasty. (We’re on ant now lol... but with very simple build, so it isn’t too bad.) I’ll let you know how it goes.

LMK if you’re ever in socal!

Re: Why I Moved Back from Gradle to Maven

#166

Post by kelnos »

usrusr wrote: post #139
kelnos wrote: post #69

Earlier quoted context omitted.

> > 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 ex…

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…

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

Re: Why I Moved Back from Gradle to Maven

#167

Post by kelnos »

orbitur wrote: post #84
kelnos wrote: post #68

Earlier quoted context omitted.

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

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.

Re: Why I Moved Back from Gradle to Maven

#168

Post by vorg »

zmmmmm wrote: post #160
lmm wrote: post #55

Earlier quoted context omitted.

I mean objectively it's not a bad language for its era, I just never found a compelling reason to use Gradle rather than something else. When I started out on the JVM I used Jython for scripting tasks since I already knew Python, and once I started using Scala I used that for, well, everything really. I don't want to get too deeply into language wars, but Java, Python and Scala all have "killer" features, things they…

> Whereas Gradle just felt like "it's a Python/Ruby/Perl-like language that runs on the JVM" - if there's something Gradle's actually the best at, their communication failed to convey it I assume you meant groovy there. But yes, I remember actually posting exactly that view on here several years ago! I felt that if I was going to learn a JVM language, why not invest that effort in something that was more generally ap…

You could be talking about Apache Groovy's seamless interoperability with Java 7. It hasn't kept up with Java 8 and lambdas, let alone Java 9 and modules.

Re: Why I Moved Back from Gradle to Maven

#169

Post by zmmmmm »

vorg wrote: post #168
zmmmmm wrote: post #160

Earlier quoted context omitted.

> Whereas Gradle just felt like "it's a Python/Ruby/Perl-like language that runs on the JVM" - if there's something Gradle's actually the best at, their communication failed to convey it I assume you meant groovy there. But yes, I remember actually posting exactly that view on here several years ago! I felt that if I was going to learn a JVM language, why not invest that effort in something that was more generally ap…

You could be talking about Apache Groovy's seamless interoperability with Java 7. It hasn't kept up with Java 8 and lambdas, let alone Java 9 and modules.

It's still far more seamless with java 8 than any other language. I don't care about superficial syntax similarity, that is not really the point. Nicer interoperability with java streams would be good though.

Re: Why I Moved Back from Gradle to Maven

#170

Post by bborud »

pleasecalllater wrote: post #145
bborud wrote: post #32

Flexibility is not something I want in a build system. I want predictability and simplicity. "Flexibility" just means that the dumbest guy on the project will find sufficient rope to hang the whole team sooner or later. That being said, "flexibility" is not special to Gradle. As long as there have been build systems there have been people who are too lazy to learn them and get "bright ideas". For instance I have no i…

Well, if you will allow such a guy to operate alone without any code review, then I'm sure you have much more serious problems in the code, than a build system.

Most complex build setups I've seen in the wild the last 5 years were made by teams that have mandatory code reviews of all code.

This isn't so much about review or not as it is about not establishing a culture where you always take the easy way out. It is tempting to think that "this will be solved through the magic of code reviews", but if you are in charge of several teams and you have to face the reality of projects living on for years with people joining and leaving the team. It is important to have empathy with developers and your future self.

Much build complexity and annoyance is due to people taking the easy way out, for instance, by scripting things that should either be adapted to make use of an existing build process, or develop a proper plugin that is documented and helps newcomers to the project understand what is going on.

If you make it easy to make ad-hoc solutions, people will build ad-hoc solutions.

Post reply on HN