Why I Moved Back from Gradle to Maven • Hacker News Board

Re: Why I Moved Back from Gradle to Maven

#141

Post by chopin » Wed, Apr 04, 2018, 10:04 AM UTC

einrealist wrote: post #58

bitcharmer wrote: post #48

Earlier quoted context omitted.

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…

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…

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.

Re: Why I Moved Back from Gradle to Maven

#142

Post by tigershark » Wed, Apr 04, 2018, 10:09 AM UTC

flukus wrote: post #113

Pxtl wrote: post #95

Earlier quoted context omitted.

Maybe combine a generic non-language specific build system (some variant of Make without the C obsession?) as the outer wrapper around a very language-oriented and inflexible/opinionated build system?

> some variant of Make without the C obsession Make doesn't have a C obsession (although the docs do), make works anywhere you have a dependency graph that can be expressed as a file timestamp. Here's an example compiling a c# project: http://flukus.github.io/rediscovering-make.html . It's much simpler than any .net build tool (and I've tried them all).

Either you have a very strange concept of simplicity or you never tried Fake.

Re: Why I Moved Back from Gradle to Maven

#143

Post by franzwong » Wed, Apr 04, 2018, 10:20 AM UTC

Recently I need to maintain a gradle script written by others. He created a Copy task, but he deleted some files inside. Every time I execute other tasks (not his task), those files are deleted. Finally I found that I need to create another Delete task and make a dependency to his task. I still don't understand those "doLast" thing very well.

Re: Why I Moved Back from Gradle to Maven

#144

Post by ailideex » Wed, Apr 04, 2018, 10:20 AM UTC

evanspa wrote: post #16

I delivered a session at JavaOne (2001?) on Ant (I was a whiz at it). Then, I had to learn Maven as it gained traction. I'm currently doing Android development, but I'm a little embarrassed to say that I don't really grok Gradle the way I do with Ant and Maven. I don't have anything against Gradle. I just don't want to spend another minute of my life learning another Java build tool. So, I stick to the Gradle default…

The biggest challenge for me when I started using gradle was understanding groovy. Once you get groovy, you get gradle. And I really like groovy now that I get it.

Re: Why I Moved Back from Gradle to Maven

#145

Post by pleasecalllater » Wed, Apr 04, 2018, 10:40 AM UTC

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.

Re: Why I Moved Back from Gradle to Maven

#146

Post by rleigh » Wed, Apr 04, 2018, 10:52 AM UTC

na85 wrote: post #60

kodablah wrote: post #45

Earlier quoted context omitted.

> needs to stop the whole convention-over-configuration idea Yup, and while we're at it, realize that the declarative approach doesn't work after the first basic uses and even though your hello world build file is simple, most people need customization. Scripting the build system should be its main feature and everything else as just shortcuts (to be fair, Gradle kinda does this w/ tasks, but doesn't make it simple t…

This may be naive but doesn't GNU Make tick all these boxes in addition to being ubiquitous?

GNU Make has a huge amount of convention over configuration. It has hundreds of built-in pattern rules!

Re: Why I Moved Back from Gradle to Maven

#147

Post by flukus » Wed, Apr 04, 2018, 11:00 AM UTC

tigershark wrote: post #142

flukus wrote: post #113

Earlier quoted context omitted.

> some variant of Make without the C obsession Make doesn't have a C obsession (although the docs do), make works anywhere you have a dependency graph that can be expressed as a file timestamp. Here's an example compiling a c# project: http://flukus.github.io/rediscovering-make.html . It's much simpler than any .net build tool (and I've tried them all).

Either you have a very strange concept of simplicity or you never tried Fake.

That's one I haven't looked at much, but can you show me a fake script that does the equivalent of my example? That means a fully incremental build, generating version files, etc. Even things like the version file tend to turn out more complicated in most build systems because they come with a half assed reimplimentation of unix tools

From a quick look t looks like it's task based instead of output based as well, so an incremental build doesn't look simple. Correct me me if I'm wrong, but it looks like it's trying to be a better nant, not a better make.

Re: Why I Moved Back from Gradle to Maven

#148

Post by chii » Wed, Apr 04, 2018, 11:16 AM UTC

wst_ wrote: post #109

chii wrote: post #90

Earlier quoted context omitted.

All maven builds are exactly the same (unless they force the tool to do otherwise), and files are always in well known locations.

How that's different in Gradle?

If your build generated sources (such as via antlr or some other lexer/parser that has a maven plugin) at build time, you know that it's likely to be done at the 'process-sources' phase.

If you wrote a custom gradle build script (or indeed, any other custom scripts), then you cannot be sure when that generation of sources is going to happen.

Maven forcing you to design your build around maven's fairly strict set of phases (and build lifecycle) means you confirm, and any tooling can compose as long as they also conform.

Re: Why I Moved Back from Gradle to Maven

#149

Post by mgkimsal » Wed, Apr 04, 2018, 11:31 AM UTC

lmm wrote: post #25

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…

> Now we simply have bash scripts that do all our one-offs that often were nightmares to accomplish in Gradle or Maven. Whether it is JAXB or Docker integration every maven/gradle plugin I ever used was 10 times harder than just bash. This is the opposite of my experience. Trying to get consistent behaviour out of bash scripts is a nightmare (every nontrivial bash script has an undocumented dependency on a particular…

> every time you try to build on a new machine you're rolling the dice

why not on copies of known-good machines? vm boxes with the same definitions would alleviate almost all of that 'roll the dice' aspect, no?

Re: Why I Moved Back from Gradle to Maven

#150

Post by Steeeve » Wed, Apr 04, 2018, 11:33 AM UTC

The problem with build systems is that people try to do too much with them.

It wouldn't be so bad, if there was consistent, thorough documentation available, including for the various plugins that people put together and shared.

But where things stand it's entirely too easy to have builds that only a few people really understand as they read through the build definitions.

At their heart, builds are simple. Pull in dependencies. Process templated files. Copy files. Run a test suite. Compile/link/etc.

Yet, with large projects there always seems to be something unique that requires a custom plugin or a day and a half trying to figure out how to move a particular step, or heaven forbid running the same kind of step twice at different stages.

The way I see it - if you have to spend a day figuring out how to do anything with your build system, you have eliminated the benefit of said build system. You might as well build a shell script in half an hour that does what you want it to do. If someone can come along later and say "that's easy with ant/maven/gradle/buildr/make/etc." and can throw it together quickly along with a quick doc explaining the steps, then fantastic.

I think time is better spent writing software than struggling through learning a build environment.