
Why I Moved Back from Gradle to Maven - ognyankulev
https://blog.philipphauer.de/moving-back-from-gradle-to-maven/
======
bborud
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 idea how many shellscript-infested
build setups I've seen for C programs that could easily have been built using
entirely standard Makefiles. If the author had bothered learning to use
Makefiles.

~~~
kodablah
> Flexibility is not something I want in a build system. [...] "Flexibility"
> just means that the dumbest guy on the project will find sufficient rope to
> hang the whole team sooner or later.

We're on opposite sides here. I can control my team wrt rope and what not. But
it's very hard to wrangle a build system to perform some advanced task you
need without flexibility. I'd way rather have problems with the build system
users than the build system authors. One is more easily fixable.

~~~
madmax96
I've experienced this myself in a number of different environments. But I'm
still not satisfied with the results with the more flexible tooling, usually.
I think it's because they commonly lack scaffolding that I want a majority of
the time.

The older I get, the more I realize that the lisp DSL approach is probably
best: provide a simple, declarative walled garden. If I want to change
something for my project using the full language, let me, and may the PR
reviewers determine my fate. Ruby also seems to adhere to this philosophy,
although I don't have a lot of experience with it.

~~~
kodablah
> may the PR reviewers determine my fate

Confused here. I can't really stop progress waiting on build system features.
Extensibility is required like a programming language. Otherwise, you must
stop using the build system or build wrappers around it or outside of it
making your build even more bespoke than if you used a more flexible system.

~~~
bonesss
That's my issue: missing build system capabilities leaves me writing console
apps to make builds sane.

If I'm writing code anyways in MyLanguage to compensate for MyBuildScript, why
aren't my build scripts written in MyLanguage?

------
wendelinsky
Yo, new Gradle developer experience lead here. I fully empathize that it's
much too difficult to wrap one's head around Gradle, so I want to share some
things you might find interesting:

* The Gradle Kotlin DSL, which is nearing production-readiness, substantially improves the assistance/docs one gets through the IDE.

* However, the Kotlin DSL does not help with the large API surface and understanding of Gradle concepts, so I have been working on improved docs and best practices for the past few months.

* However, most folks don't or won't read docs, so additional tools will help users opt-in to strictness and quality checks that enforce best practices through the tool.

Even with all that, one can think of build tools like languages: one tool will
never be able to suit all needs or projects. However, I intend the broaden the
audience for Gradle by making it more accessible to a wider audience.

I'd love your help. My Twitter DMs are open @eriwen. DM me the 1 specific
thing you would change about Gradle if you could.

[EDIT]: Fixed the formatting of the bullet points.

~~~
bsder
Fix the documentation!

Focus on Android Studio because that's the only place people really use Gradle
because they are forced to do so.

You need to create a _LOT_ of Android Studio sample projects, and they need to
be _kept up to date_ for the various versions of Android Studio. If you did
nothing but create "Hello World" in a zillion various flavors (Java, Kotlin,
Scala, NDK, NDK with static library on different architectures, etc.) for
people, that would be huge.

 _My_ specific beef is with NDK projects. Pulling in static libraries and
compiling them with the NDK is a mix of magical keywords that sometimes
materialize from some kind stranger via chat--generally because Gradle has to
shove those keywords to something like CMake--which _ALSO_ has an enormous
learning curve.

~~~
dljsjr
Please don't say that nobody uses Gradle outside of Android devs. We're a shop
that definitely does zero Android development and we still use Gradle, the
fact that people assume Gradle <-> Anroid Dev is already a huge pain point for
us when we start looking for third party educational resources.

~~~
pjmlp
At our shop we only care about Gradle, because Google forces ud to.

Otherwise we would keep using only Maven for Java projects.

Slower builds and higher hardware requirements for daemon and build cache are
not worth it.

------
lmilcin
I moved from Maven to Gradle about two years ago and I am not going to look
back.

I understand the arguments made in article and I am the Gradle ninja in my
project so I may have subjective view on the whole topic.

My points:

\- Maven requires a lot of boilerplate for everything. Copy-paste. I need to
instruct everybody on what to copy, where to paste, and how to edit and what
they should not touch under any circumstances.

\- Gradle... It's an environment for programmer! I just write a bunch of code
in Kotlin so that all 100 projects have a bit of my custom DSL that suits the
needs of our application. The code takes the DSL and does all the job behind
the scenes and most developers don't need to understand it. They can, but they
don't need to. This is how it is supposed to work -- in a large project people
specialize and the application should be created in a way that will allow
people to not have to understand everything.

\- Maven is strictly declarative. If you can't find a plugin you either dig up
Ant or you have to write your own plugin. Not nice.

\- In Gradle I can have almost everything declarative but I have the freedom
to drop this bit of logic where it is really needed.

\- Don't try to make it too complex just because you start using Gradle. Great
power comes with great responsibility.

If I wanted to change one thing in Gradle it would be for the Gradle project
to focus on debugging. I really find it difficult to figure out why things
fail even though I have almost 20 years of experience with various languages
and a decade of very intimate experience with Java. Make it easier so that
people are not put off.

~~~
bitcharmer
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
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
> _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
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
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
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.

------
chvid
I have been a user of make, Ant, Maven and Gradle. And Grunt, Gulp and now npm
+ webpack in the JavaScript-world. And of all these Maven is by far the better
build tool.

To the creator of these tools: Try to remember that what you are creating is a
support tool. A second act to the main development language. It is better if
it is not general purpose, it is better if it is not turing complete, it is
better if it is less powerful.

~~~
andrewmcwatters
I don't spend a whole lot of time in the Java world, just enough to take care
of small requests. So, I've only experienced maybe half of those. Could you
explain a few killer reasons why Maven is the better build tool?

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

~~~
wst_
How that's different in Gradle?

~~~
pjmlp
You are actually programming in Groovy, with all the plus and minus it
entails.

Regarding the execution speed, IDEs not able to autocomplete, no guarantees
about the format that IDEs can easily parse, and it often breaks between
releases.

Then to compensate for lack of speed, you need to have a running daemon and an
in-memory build cache.

------
rhacker
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 to build the Java
code. Things like Docker, Java code generation and a variety of other tasks
you often do for releases, I finally figured out what I needed to do:

Make sure everyone on the team can run Bash. From there I could stop worrying
about Windows users - Git Bash or Babun or some flavor of Cygwin. And things
are even better with Linux Subsystem for Windows.

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.

When you start taking out all the other stuff it started to become clear that
Gradle was winning out. With gradle I can build my code and get a variable
that represents every JAR I need for a deployment into a Dockerfile containing
folder. So that's where I personally ended up liking Gradle more - because I
stopped depending on Maven and Gradle to do the other kitchen sink tasks.

~~~
kovrik
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 the same command and get the same result, and not waste
time learning custom scripts for each project.

~~~
Consultant32452
This is a common problem for programmers in general, not just at build time.
Occasionally you will run into a case where the framework you've chosen just
doesn't fit. You can try to hammer your need into the framework in some
horrific fashion or your can temporarily circumvent it for this one task.
Which path you go depends on a lot of factors.

------
djsumdog
I've used Maven, Gradle and SBT in major commercial projects. I don't
understand this Maven love honestly. Maybe everything I had to work on was
just setup incorrectly, but the horrid overly verbose xml configuration files
combined with the fact that maven constantly recompiled things it didn't need
to and was sooo slow.

I think the only good thing from Maven was the directory structure layout
(src/{main,test}/{java,scala,groovy,resources}) which has carried on to other
build system. I didn't like that at first too, but I've since come around.

SBT does a lot of things really nicely if you're in the Scala world. `sbt
console` is wonderful. That being said, never take up the sbt source code and
try to hack on it. That's a disgusting mess under there. Also the whole task
dependency/macro structure can get pretty awful when you want to run tasks
with multiple configurations in one go. I don't think it's possible. The sbt-
native-packager works really well, but once again, that source code will make
you want to throw up. At least back in like 2014 it did. Who knows. Maybe it's
gotten better.

Honestly all the build systems are kinda terrible, but I'd take groovy or sbt
any day over maven. I don't see how anyone likes it. Trying to figure anything
out in Maven was just miserable.

~~~
pjmlp
We love it, because not everyone suffers from XML allergy, which is way more
toolable and easily integrated into IDEs than tools using the programming
language of the day.

Ant and Maven just work on IDEs and on Netbean's case, they are even the
official project format.

------
derriz
I can see the attraction in a build system based on a proper full featured
programming language but I've never been tempted to try gradle because I
believe the approach has a fundamental flaw. I.e. that it's impossible for
IDEs to reliably extract useful project structure from the build description.

Even as a 25 year vi/vim user, I've succumbed to depending on IDEs more and
more and I believe that any proposed build system has to easily support
deep/rich integration with IDEs. This is theoretically impossible if the build
system is effectively a general Turing-complete programming language. At best
you will be able to provide brittle integration or else the IDE will have to
dumbly treat the entire build process as a black box.

~~~
dljsjr
The integration with IDEA and Eclipse for Gradle is actually quite good, the
only downside is that it's "one-way". That is to say that you can't use the
IDE's GUI to configure your build.

Gradle enables this as a first-class citizen by providing a "Tooling API":
[https://docs.gradle.org/current/userguide/embedding.html](https://docs.gradle.org/current/userguide/embedding.html)

I know that Buildship, the Eclipse plugin that integrates Gradle, is actually
worked on pretty heavily by Gradle contributors. I don't know about IDEA but
that's the IDE that I use for Java development and the Gradle integration is
very, very good.

~~~
pjmlp
It is still not as good as Ant and Maven support, which allow two ways, and
are even the project formats used by Netbeans.

------
hodgesrm
This pretty much matches my experience. I resisted maven and the obscure
pom.xml structure for a long time but eventually came around due to its
excellent dependency management. Now that I understand maven it's hard to see
how Gradle really improves on maven for basic Java projects.

~~~
oftenwrong
Seems "obscure", but it has a schema.

~~~
hodgesrm
Just to be clear, I'm not against XML at all. Maven does more but can be a
pain to program compared to older systems like ant, which is also XML-based.
Configuring plugins to fire at the right point in the build cycle (e.g.,
package vs. install) comes lightly to mind.

It's gotten a lot better because there are many examples now accessible with
Google. Overall I'm pretty happy with maven now. It works.

~~~
oftenwrong
"It's gotten a lot better because there are many examples now accessible with
Google."

That is the main reason I am sticking with Maven (where practical). Examples,
documentation, and answered questions are plentiful.

"Configuring plugins to fire at the right point in the build cycle (e.g.,
package vs. install) comes lightly to mind."

The official documentation has that covered well:
[https://maven.apache.org/guides/introduction/introduction-
to...](https://maven.apache.org/guides/introduction/introduction-to-the-
lifecycle.html)

An example they give is:

    
    
      ...
       <plugin>
         <groupId>com.mycompany.example</groupId>
         <artifactId>display-maven-plugin</artifactId>
         <version>1.0</version>
         <executions>
           <execution>
             <phase>process-test-resources</phase>
             <goals>
               <goal>time</goal>
             </goals>
           </execution>
         </executions>
       </plugin>
      ...
    

i.e. plugin "display-maven-plugin" should execute its "time" goal during the
"process-test-resources" phase.

IIUC, there are no fixed phases in Gradle, so this sort of thing is done with
task dependencies.

------
rb808
> "Great Flexibility. Highly customizable build. You can easily create your
> own task and do whatever you want."

Usually this is a red flag for me. People's apps really aren't that different,
if you're doing some weird customization its going to be a nightmare for the
next guy to maintain.

~~~
blktiger
To me the beauty of Gradle is the complexity is hidden behind plugins so that
the majority of builds are simple. I’d say a basic java build in gradle is
simpler than the equivalent maven xml. The power is there for when you need
it, but the basic plugins are easily configured for the basic stuff.

------
evanspa
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 defaults when creating a new project in
Android Studio, and rely on SO and whatnot whenever I need to customize.
Haven't been burned yet.

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

------
zmmmmm
The whole article could be written about moving to maven. I still have no idea
about how to do even trivial modifications to maven builds without googling
them.

Fwiw, the need to learn groovy is a bit of a red herring because it doesn't
help that much: I know groovy very well but I still find gradle confusing and
have to google everything. My favourite build system of all time was gant,
also based on groovy but a simple wrapper for ant. It had zero magic, was just
a systematic wrapping of the ant API which itself was just a bunch of well
documented useful build utilities. I found it very easy to use. The contrast
between two build systems both based on the same dynamic language was very
stark to me.

------
ynezz
> Gradle features: Great Performance

Did I missed the sarcasm tone? I've never experienced slower build systems
then those used in Java world, like Gradle for example.

~~~
sidlls
People complain about C and C++ compile times but they don't hold a candle to
that in Android-Java-land in my experience.

~~~
pjmlp
Yep, specially when you get to join NDK and Gradle builds.

It is not time for coffee, rather lunch.

------
ognyankulev
Reddit discussion:
[https://www.reddit.com/r/java/comments/89adwf/why_i_moved_ba...](https://www.reddit.com/r/java/comments/89adwf/why_i_moved_back_from_gradle_to_maven/)

------
dcposch
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 released much of
the original as open source, renaming to Bazel.

Maven and Gradle are both flaky, slow, and annoying to configure, in my
experience.

~~~
NovaX
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
more than Blaze these days, and I'm too exhausted to do it just for fun. I
think there is also a bit of Stockholm syndrome at play, since I convinced
myself it was not too bad back at Addepar.

~~~
dcposch
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!

------
oftenwrong
I went back to maven. I had trouble finding solutions to gradle issues when I
got stuck. Maven solutions are easier to find. This will probably change as
gradle becomes more popular.

I should add that I am no Java guru, so for me this is an important
consideration. Still, the real Java gurus at my company are split on the
issue. We have projects on both build systems.

------
tunesmith
One thing I haven't figured out in Gradle is that (in IntelliJ) in a maven
pom, I can command-B to find the pom definition of a parent pom or a
dependency. command-B in gradle doesn't do anything there. Anyone know the
magic command?

~~~
humbleMouse
Asking the real questions.

------
sytse
We're planning to add a Maven compatible artifact repository to GitLab. I
assume that will automatically also work with Gradle, or is there more to it?

~~~
djsumdog
Yep, you can publish to a maven repository from Gradle pretty easily. I just
setup a project to publish from gradle -> artifactory last week.

~~~
sytse
Cool, thanks!

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

------
Traubenfuchs
When I think of Gradle I think of the countless software development shacks
where no one can understand or extend the Gradle configuration because
someone, years ago, thought it would be cool to be hip and use Gradle instead
of Maven, left the company and now nobody is interested in learning it.

------
kodeninja
Probably unrelated, but Java really needs to fix its Classpath Hell issues. On
so many sufficiently large Java projects, you end up descending into the
inclusion/exclusion madness with your build files because your app is
inheriting `log4j` from 50 different libraries. Or the infamous xerces
hell[1]. And fixing that in maven is not pretty :(.

[1] [https://stackoverflow.com/questions/11677572/dealing-with-
xe...](https://stackoverflow.com/questions/11677572/dealing-with-xerces-hell-
in-java-maven)

~~~
jryan49
Wasn't Java 9 modules supposed to help address these issues?

~~~
aiCeivi9
No, it is supposed to reduce surface area between modules/jars. Before Java9
library creators could only add "internal" to their packages name and hope end
users won't touch it.

The introduction of modules might actually make version hell even worse:
[https://blog.codefx.org/java/dev/will-there-be-module-
hell/](https://blog.codefx.org/java/dev/will-there-be-module-hell/)

------
dmix
The advantages/drawbacks section could easily apply to Java as a language
itself as much as to Gradle. Flexibility and performance traded for unending
complexity, all-encompassing scope (creep), and the subsequent unpredictable
behaviour/side-effects which the latter creates.

Which makes this backlash entirely unsurprising because the mainstream
foundational tools will eventually end up reflecting the culture of the
programming language, given enough development time and an unconstrained
mandate seeking to keep the wider community happy.

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

------
nimrody
Given that Gradle is here to stay... Can anyone share good resources for
understanding Gradle?

With complex Makefiles, at least you have the sources and can try to
understand the logic. With Gradle, it's all tons of compiled java code.

------
dionian
As someone with extensive exprience with both, my opinion is that Kotlin will
greatly tip the scales in Gradle's favor, and I'll probably switch to that as
my preferred choice for non-scala projects

------
winrid
What about the performance benefits (ie, incremental builds being broken in
Maven)? EDIT - to clarify - has anyone found a way to make Maven just as fast?

We have Maven builds that can take an hour and Gradle drops that down to
minutes (or less than a minute).

------
wkoszek
I work on full-stack product, with iOS/Android SDK element that other people
integrate in their apps. Server-side with UNIX boxes: everything works always.

Xcode/iOS: we published CocoaPods. It was pain to get to work reliably on
laptops/Jenkins b/c of upgrades to Ruby, but if you lock yourself to one Ruby
version, and lock the Gemfile, it's mostly OK. At least it's pretty obvious
when/why it doesn't work.

Gradle: it's such a mess. I don't even know where to start. I don't know
Maven, but Gradle error warnings are the worst. 4 lines, tells you nothing,
with turned on debugging the output tells you nothing, while e.g.: in reality
you don't have the child-repo checked out because you forgot to `git submodule
update --init`.

Getting Gradle to work on a laptops across the team of 4 was a pain. We had
cases where two people with the same AS version and the same gradle version
couldn't import the project into AS. Our instructions are - after 'git pull'
make sure you do 'git clean -dfx' and re-import the project.

Personally 50% of time when I start Android Studio I have some critical
exception of some sort, each time from Gradle window. There's this, plus
gradle wrapper. I pretty much never worked for me. This is meant to solve
problems with always getting you the right Gradle version, but this is sci-fi.
I believed it's just me who uses SDKMan to be able to fetch the right gradle
which our project depends on, but others around do too. Otherwise it's a pain
in the ass -- and `brew` doesn't have the gradle's we need, because they
migrated to the very latest one, when in production you'd rather have older
version for an extended period of support time.

If you, just like us, have a project which has 3+ years of scar tissue and it
has to integrate with javanet, picasso, okhttp, volley etc. and you have
several people who fetch and integrate your code in their apps--I feel really,
really sorry for you.

DSL is all right, and maybe Groovy has some unique features, but I never
discovered them. This is Java language that isn't Java, or some dialect of
Java-like language aimed to make Java 3% better, but to be honest I don't hear
people writing Groovy for fun and pleasure. So to me it was a cost of learning
basic stuff just to be able to automate simple stuff in Android build system
(when we run ./jenkins.sh --local, we want our Android functional tests to hit
local dev environment). Of course in XCode it works 100% better and took 20%
of time to do, since Apple owns XCode and made it look better: go to project
settings, drop in the path to post/pre built scripts to customize your flow,
and in a language you already know. Google, who subleases Android Studio from
JetBrains, had no choice and made Android ecosystem look like a Frankenstein.

~~~
pjmlp
> I don't hear people writing Groovy for fun and pleasure.

It was common at local JUGs almost 10 years ago, when there was lot of hype
around Groovy and Grails.

Even at JSF Days 2007 there were some talks about adding Groovy support to JEE
as a means to write session and entity beans.

Nowadays Gradle is the only thing keeping Groovy from completely fading away.

That and Grails maintenance projects.

------
tomohawk
We moved to apache buildr years ago and never looked back.

[https://buildr.apache.org/](https://buildr.apache.org/)

~~~
somecoderguy
Funny that, because I spent 3 months removing buildr and adding maven on a
large, complex project. After a couple of years into buildr, the build had
grown so artisanal that even breaking a jar out of one of the build's modules
was a multi-week task. After we moved, multiple modules were made into jars
and some even wound up becoming external projects very easily.

Everything was done in scripts (predictable when you offer nothing else) and
it was so misconfigured and esoteric that nobody happened to notice that it
was reaching out to the wrong server for artifacts....WHOOPS!

Dependency management was awful and g'luck even getting something as simple as
a dependency tree out of the system. Oh and it appears to lack any mindshare
so nobody appears to be improving it and g'luck if you happen to need some
help with it.

The problem with buildr is that it's a ruby based build system for Java. Why?
Who wants to write their Java build code in Ruby, and why can't they just go
work in a RoR company already?

Builds shouldn't be interesting, artisanal, or occupy a lot of your time. They
should just produce the artifacts and move on.

Since the switch to Maven I find myself worrying about the builds a lot less
and actually working on code instead.

------
eecc
Maven’s approach is a lost cause: you either expect any user to coerce their
case into your model (and hope the plugin is documented, dependencies work
(bwahahaha) and is maintained) or you breakout to some exec plugin and give up
on platform agnostic builds.

Sure, it’s an unforgiving ambition and many other systems fell trying, but it
was their choice.

With Gradle the blame falls squarely at the feet of plugins, and you’re on
your own (which has always been the case anyway)

~~~
lmm
> you either expect any user to coerce their case into your model (and hope
> the plugin is documented, dependencies work (bwahahaha) and is maintained)

I find all the cases can be coerced, and it's not even hard. Some users seem
to insist on customization for its own sake, "oh I absolutely _must_ call my
source folder source rather than src", but Maven does the right thing by
ignoring those users, with the result that you can pick up any project that
uses Maven and be immediately productive.

~~~
Macha
The case I remember was a couple of years ago. We had a test runner for our JS
code that was delivered by our Java webapp. Part of that configuration was the
list of flags to a maven plugin. The issue was that we had two orthogonal
configuration options that affected the list of flags. Initially, it used
HTMLUnit and didn't record coverage statistics. We wanted to record coverage,
and also switch to PhantomJS (when it was new) over HTMLUnit. Our test times
were as follows:

PhantomJS - 1 min

PhantomJS + Coverage - 5 min

HTMLUnit - 10 min

HTMLUnit + Coverage - 25min

Coverage required one set of additional flags, PhantomJS required another. But
we could only replace the test runner string, not add to it. We couldn't drop
HTMLUnit altogether, as our company mandated CI system would not make it easy
to install PhantomJS. And tests were still new to many team members so if we
defaulted coverage on, nobody would run it with those times. So ideally we'd
have mvn test -Pphantomjs -Pcoverage if we wanted phantom with coverage. But
actually we had to do mvn test
-P{phantomCoverage,htmlUnitCoverage,phantomNoCoverage,htmlUJnitNoCoverage}
which meant copy pasting a substantial chunk of our pom file 4 times to change
two lines of it, rather than a base case with two overrides.

~~~
lmm
Ok, good example of the tradeoff maven makes. My view is: it's worth making
that kind of inherently complex case complex for the sake of the
comprehensibility advantage that all projects gain from having the entire test
runner string in one fixed place where a reader can look for it. Some test
plugins do provide a separate "extraArgs"-type config that you can use for
that kind of case, but I'm not convinced that it's a good idea.

------
jillesvangurp
I've used both; ant as well in the distant past. More gradle than maven lately
but I still have a few maven projects. True for both is that you don't want to
push them beyond simple stuff. It just gets ugly and most of your team will
look the other way when it is time to sit down and fix the build (usually that
job lands in my lap).

There are maven and gradle plugins for just about everything and it is
tempting to use them but your build files will quickly become very complex and
unmaneagable. Worse, a lot of these plugins are poorly documented, if at all,
and tend to not add a lot of value. And that's before you start hitting the
corner cases, bugs, and left as an exercise to the reader type stuff that just
requires copy pasting bits of half working stuff from all over stackoverflow.
Once you go down that path, maven and gradle are equally frustrating.

Solution in both cases is to simply not even try to do everyting in a build
file and fall back to simple alternatives: use a small run.sh instead of
trying to get some unholy maven xml blob or gradle script to fork off a jvm
just right; really a script is a lot easier to write, maintain and it does
exactly what it says. And even better, you get to reuse it in the last line of
your Dockerfile where you start your software.

Speaking of Docker, packaging things up as a docker image (or rpm, or
whatever), is also definitely out of scope for build files. I'm sure it is
possible to do with some unholy combination of craptastic plugins in both; but
why even bother? Just use a Dockerfile and docker build for that. They are
nice and simple and any decent devops person knows how to work with them.

Actually, in some of my projects the whole build is a docker build. It's
great! I let it take care of downloading the jdk, gradle/mvn, and then let it
download the world as a separate docker layer before letting it build the
software. Most of the builds it jumps straight to building software unless I
touch the build file. Also makes for really simple CI: all your build server
needs to know is docker. Also people can build and run your software without
installing anything else than docker (and git, and maybe a few other bits and
pieces). Add some docker compose and you can do integration tests (another
thing that you should not attempt from a build file).

Also, with both maven and gradle: avoid multi module setups. They slow down
your builds, multiply your complexity, and all for the illusion of not quite
having reusable components. Once you have two modules, you will need three,
and four, etc. There's no end to it. Just don't. Usually you are just looking
at Conway's law in action: it rarely buys you anything but misery and slow
builds. KISS & YAGNI.

~~~
solatic
> I let it take care of downloading the jdk, gradle/mvn, and then let it
> download the world as a separate docker layer before letting it build the
> software.

Including your source code inside your Docker image unnecessarily inflates the
size of your Docker image, including (seemingly from your description) the
entire version control history. For big projects (especially big projects
where junior engineers didn't get the memo that you shouldn't check binary
files into Git...), this can easily add hundreds of megabytes if not gigabytes
to the size of the image.

Docker isn't a build system (which is responsible for the creation of both
inflated-but-easily-debuggable as well as optimized-for-production), it's a
combined packaging system and runtime.

------
khana
Concur. I found Gradle to be to far removed from the truth so to speak. I like
Maven's declarative xml and its promulgation of the build life-cycle. This
makes a complex build easier to maintain in the long run imo.

------
acrive
Because you don't know Groovy. Simple.

Maven it's only in your comfort zone. Bye.

~~~
lmm
Gradle scripts are an undocumented superset of Groovy. It's not just Groovy,
it's the fact that there's no consistent way to know what settings and
defaults come from where.

(And really, why _would_ you know Groovy these days? Is it even used for
anything outside of Gradle anymore?)

~~~
acrive
* Easy to read * Collections tools * Functional programming with closure * Traits * Typed or not * DSL * 100% compatibility with all jars * Awesome framework like Grails and the upcoming Micronaut and SpringBoot * Enterprise software or script, you're welcome.

There is a whole world out there.

~~~
pjmlp
Yeah, time travel to JUG meetings 10 years ago.

Nowadays all of that is a synonym to Grails maintenance projects.

