16 ms·

Why I Moved Back from Gradle to Maven

174 points by ognyankulev 9y ago

ognyankulev 9y ago
Reddit discussion: https://www.reddit.com/r/java/comments/89adwf/why_i_moved_back_from_gradle_to_maven/ https://www.reddit.com/r/java/comments/89adwf/why_i_moved_ba...
hodgesrm 9y ago
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.
- eecc 9y ago
  Well, excellent... their versioning is so broken that it had to become a de-facto standard to become accepted
  - hodgesrm 9y ago
    Which versioning do you mean? Of Maven itself?
- oftenwrong 9y ago
  Seems "obscure", but it has a schema.
  - hodgesrm 9y ago
    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 9y ago
      "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-the-lifecycle.html https://maven.apache.org/guides/introduction/introduction-to... 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.
rhacker 9y ago
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 9y ago
  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 9y ago
    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.
rb808 9y ago
> "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 9y ago
  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.
- vbezhenar 9y ago
  If someone wants customization, he'll do it. If build tool will be on his way, he'll write PowerShell script, generating Perl script using M4 and you'll live in a some special level of a nightmare. Gradle has a lot of plugins, so typical builds are possible just like Maven (there might be exceptions, of course), but if you need to customize something, I think that being able to write an ad-hoc task with Gradle is better than not being able to do so.
wendelinsky 9y ago
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 9y ago
  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.
  - wendelinsky 9y ago
    Thanks for the feedback. Docs/samples oriented around Android could use some love for sure. I think one thing we need to figure out is how Google and Gradle can accomplish these things together.
    - 9y ago
oftenwrong 9y ago
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.
eecc 9y ago
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 9y ago
  > 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.
  - vbezhenar 9y ago
    I'm not sure what's your point, but Maven allows to change source folder very easily. Maven has sensible defaults, that's right.
  - Macha 9y ago
    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.
khana 9y ago
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.
tomohawk 9y ago
We moved to apache buildr years ago and never looked back. https://buildr.apache.org/ https://buildr.apache.org/
- somecoderguy 9y ago
  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.
evanspa 9y ago
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 9y ago
  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.
derriz 9y ago
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 9y ago
  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 9y ago
    It is still not as good as Ant and Maven support, which allow two ways, and are even the project formats used by Netbeans.
- vbezhenar 9y ago
  Idea works fine with non-trivial Gradle builds. It might be theoretically impossible, but on practice it works.
- tsvetkov 9y ago
  I think it's not correct to say that Turing-completeness somehow prevents extracting project structure. If a build tool can extract that information, why IDE could not do that? In fact this is how Gradle projects are imported into Intellij and Eclipse: Gradle builds project model by running Groovy or Kotlin scripts, and then IDEs are working with declarative model. The real problem is working with scripts themselves: changing them automatically (applying refactorings), providing good completion, navigation, etc. The dynamic nature of Groovy makes it much harder for IDEs to provide good tooling, but even with statically typed Kotlin it is hard because Gradle APIs are very dynamic in nature (lots of string typed APIs). That does not mean that Turing-completeness prevents good tooling completely, it just requires more efforts and has some limits depending on a build tool`s software model.
ynezz 9y ago
> 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.
- acrive 9y ago
  https://blog.gradle.org/introducing-incremental-build-support https://blog.gradle.org/introducing-incremental-build-suppor...
- sidlls 9y ago
  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 9y ago
    Yep, specially when you get to join NDK and Gradle builds. It is not time for coffee, rather lunch.
- vbezhenar 9y ago
  Are you talking about Android? I'm using Gradle for traditional Java projects (standalone and web) and its performance was good, similar to Maven. I agree that Android plugin is very slow, but I think that it's not a Gradle to blame.
- derptron 9y ago
  Gradle is objectively faster than Maven. Android projects suffer heavily due to multidexing.
acrive 9y ago
Because you don't know Groovy. Simple. Maven it's only in your comfort zone. Bye.
- lmm 9y ago
  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 9y ago
    * 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 9y ago
      Yeah, time travel to JUG meetings 10 years ago. Nowadays all of that is a synonym to Grails maintenance projects.
  - zmmmmm 9y ago
    Groovy is actually an extremely useful language to know. Something approximating bash for java, but with capability to scale up to full application development. Gradle would be one of the less important reasons to learn it imho.
    - lmm 9y ago
      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 offer that no other language does - you may not agree with them but there are reasons someone might pick that language over every other language in the world. 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.
bborud 9y ago
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 9y ago
  > 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.
  - freedomben 9y ago
    I agree. With an inflexible build system we still end up with the nasty shell script but it's worse because it wraps the build system.
    - Pxtl 9y ago
      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?
      - flukus 9y ago
        > 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 http://flukus.github.io/rediscovering-make.html . It's much simpler than any .net build tool (and I've tried them all).
chvid 9y ago
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 9y ago
  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 9y ago
    All maven builds are exactly the same (unless they force the tool to do otherwise), and files are always in well known locations.
    - wst_ 9y ago
      How that's different in Gradle?
      - pjmlp 9y ago
        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.
      - chii 9y ago
        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.
lmilcin 9y ago
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 9y ago
  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 9y ago
zmmmmm 9y ago
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.
dmix 9y ago
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.
jillesvangurp 9y ago
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 9y ago
winrid 9y ago
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 9y ago
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.
- 9y ago
tunesmith 9y ago
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 9y ago
  Asking the real questions.
kodeninja 9y ago
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-xerces-hell-in-java-maven https://stackoverflow.com/questions/11677572/dealing-with-xe...
- foobarchu 9y ago
  I hit this just recently with an in-house dependency injection library. We upgraded the version in an application, it worked great, we deployed it to a cloud environment. Lo and behold the application wouldn't start up, and more importantly wouldn't give us a real reason why. In the end I discerned from cryptic logs that it was because Java had loaded up both the jar of the version we wanted and the jar of an older version that happened to be in the classpath too. You can't have two dependency injection systems running at the same time, so they fought and came to a stalemate. Deleted the bad version and it was all good. I know that this isn't entirely Java's fault, as that second jar shouldn't have been there to begin with, but it's pretty ridiculous that two versions of the same dependency can be loaded and in use at the same time.
- jryan49 9y ago
  Wasn't Java 9 modules supposed to help address these issues?
  - aiCeivi9 9y ago
    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/
sytse 9y ago
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 9y ago
  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 9y ago
    Cool, thanks!
dionian 9y ago
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
djsumdog 9y ago
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 9y ago
  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.
dcposch 9y ago
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.
- pjmlp 9y ago
  Because in the Java world no one really cares about Bazel.
- NovaX 9y ago
  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 9y ago
    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!
nimrody 9y ago
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.
Traubenfuchs 9y ago
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.
franzwong 9y ago
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.
Steeeve 9y ago
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.

174 points by ognyankulev 9y ago

Reddit discussion: https://www.reddit.com/r/java/comments/89adwf/why_i_moved_back_from_gradle_to_maven/ https://www.reddit.com/r/java/comments/89adwf/why_i_moved_ba...

hodgesrm 9y ago

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.

eecc 9y ago
Well, excellent... their versioning is so broken that it had to become a de-facto standard to become accepted
- hodgesrm 9y ago
  Which versioning do you mean? Of Maven itself?
oftenwrong 9y ago
Seems "obscure", but it has a schema.
- hodgesrm 9y ago
  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 9y ago
    "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-the-lifecycle.html https://maven.apache.org/guides/introduction/introduction-to... 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.

rhacker 9y ago

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 9y ago
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 9y ago
  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.

rb808 9y ago

> "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 9y ago
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.
vbezhenar 9y ago
If someone wants customization, he'll do it. If build tool will be on his way, he'll write PowerShell script, generating Perl script using M4 and you'll live in a some special level of a nightmare. Gradle has a lot of plugins, so typical builds are possible just like Maven (there might be exceptions, of course), but if you need to customize something, I think that being able to write an ad-hoc task with Gradle is better than not being able to do so.

wendelinsky 9y ago

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 9y ago
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.
- wendelinsky 9y ago
  Thanks for the feedback. Docs/samples oriented around Android could use some love for sure. I think one thing we need to figure out is how Google and Gradle can accomplish these things together.
  - 9y ago

oftenwrong 9y ago

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.

eecc 9y ago

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 9y ago
> 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.
- vbezhenar 9y ago
  I'm not sure what's your point, but Maven allows to change source folder very easily. Maven has sensible defaults, that's right.
- Macha 9y ago
  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.

khana 9y ago

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.

tomohawk 9y ago

We moved to apache buildr years ago and never looked back. https://buildr.apache.org/ https://buildr.apache.org/

somecoderguy 9y ago
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.

evanspa 9y ago

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 9y ago
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.

derriz 9y ago

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 9y ago
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 9y ago
  It is still not as good as Ant and Maven support, which allow two ways, and are even the project formats used by Netbeans.
vbezhenar 9y ago
Idea works fine with non-trivial Gradle builds. It might be theoretically impossible, but on practice it works.
tsvetkov 9y ago
I think it's not correct to say that Turing-completeness somehow prevents extracting project structure. If a build tool can extract that information, why IDE could not do that? In fact this is how Gradle projects are imported into Intellij and Eclipse: Gradle builds project model by running Groovy or Kotlin scripts, and then IDEs are working with declarative model. The real problem is working with scripts themselves: changing them automatically (applying refactorings), providing good completion, navigation, etc. The dynamic nature of Groovy makes it much harder for IDEs to provide good tooling, but even with statically typed Kotlin it is hard because Gradle APIs are very dynamic in nature (lots of string typed APIs). That does not mean that Turing-completeness prevents good tooling completely, it just requires more efforts and has some limits depending on a build tool`s software model.

ynezz 9y ago

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

acrive 9y ago
https://blog.gradle.org/introducing-incremental-build-support https://blog.gradle.org/introducing-incremental-build-suppor...
sidlls 9y ago
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 9y ago
  Yep, specially when you get to join NDK and Gradle builds. It is not time for coffee, rather lunch.
vbezhenar 9y ago
Are you talking about Android? I'm using Gradle for traditional Java projects (standalone and web) and its performance was good, similar to Maven. I agree that Android plugin is very slow, but I think that it's not a Gradle to blame.
derptron 9y ago
Gradle is objectively faster than Maven. Android projects suffer heavily due to multidexing.

acrive 9y ago

Because you don't know Groovy. Simple. Maven it's only in your comfort zone. Bye.

lmm 9y ago
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 9y ago
  * 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 9y ago
    Yeah, time travel to JUG meetings 10 years ago. Nowadays all of that is a synonym to Grails maintenance projects.
- zmmmmm 9y ago
  Groovy is actually an extremely useful language to know. Something approximating bash for java, but with capability to scale up to full application development. Gradle would be one of the less important reasons to learn it imho.
  - lmm 9y ago
    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 offer that no other language does - you may not agree with them but there are reasons someone might pick that language over every other language in the world. 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.

bborud 9y ago

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 9y ago
> 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.
- freedomben 9y ago
  I agree. With an inflexible build system we still end up with the nasty shell script but it's worse because it wraps the build system.
  - Pxtl 9y ago
    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?
    - flukus 9y ago
      > 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 http://flukus.github.io/rediscovering-make.html . It's much simpler than any .net build tool (and I've tried them all).

chvid 9y ago

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 9y ago
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 9y ago
  All maven builds are exactly the same (unless they force the tool to do otherwise), and files are always in well known locations.
  - wst_ 9y ago
    How that's different in Gradle?
    - pjmlp 9y ago
      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.
    - chii 9y ago
      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.

lmilcin 9y ago

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 9y ago
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 9y ago

zmmmmm 9y ago

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.

dmix 9y ago

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.

jillesvangurp 9y ago

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 9y ago

winrid 9y ago

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 9y ago

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.

9y ago

tunesmith 9y ago

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 9y ago
Asking the real questions.

kodeninja 9y ago

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-xerces-hell-in-java-maven https://stackoverflow.com/questions/11677572/dealing-with-xe...

foobarchu 9y ago
I hit this just recently with an in-house dependency injection library. We upgraded the version in an application, it worked great, we deployed it to a cloud environment. Lo and behold the application wouldn't start up, and more importantly wouldn't give us a real reason why. In the end I discerned from cryptic logs that it was because Java had loaded up both the jar of the version we wanted and the jar of an older version that happened to be in the classpath too. You can't have two dependency injection systems running at the same time, so they fought and came to a stalemate. Deleted the bad version and it was all good. I know that this isn't entirely Java's fault, as that second jar shouldn't have been there to begin with, but it's pretty ridiculous that two versions of the same dependency can be loaded and in use at the same time.
jryan49 9y ago
Wasn't Java 9 modules supposed to help address these issues?
- aiCeivi9 9y ago
  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/

sytse 9y ago

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 9y ago
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 9y ago
  Cool, thanks!

dionian 9y ago

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

djsumdog 9y ago

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 9y ago
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.

dcposch 9y ago

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.

pjmlp 9y ago
Because in the Java world no one really cares about Bazel.
NovaX 9y ago
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 9y ago
  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!

nimrody 9y ago

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.

Traubenfuchs 9y ago

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.

franzwong 9y ago

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.

Steeeve 9y ago

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.