TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Why I Moved Back from Gradle to Maven

174 pointsby ognyankulevabout 7 years ago

31 comments

bborudabout 7 years ago
Flexibility is not something I want in a build system. I want predictability and simplicity. &quot;Flexibility&quot; just means that the dumbest guy on the project will find sufficient rope to hang the whole team sooner or later.<p>That being said, &quot;flexibility&quot; 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 &quot;bright ideas&quot;. For instance I have no idea how many shellscript-infested build setups I&#x27;ve seen for C programs that could easily have been built using entirely standard Makefiles. If the author had bothered learning to use Makefiles.
评论 #16749690 未加载
评论 #16750891 未加载
评论 #16752812 未加载
评论 #16750287 未加载
评论 #16753514 未加载
wendelinskyabout 7 years ago
Yo, new Gradle developer experience lead here. I fully empathize that it&#x27;s much too difficult to wrap one&#x27;s head around Gradle, so I want to share some things you might find interesting:<p>* The Gradle Kotlin DSL, which is nearing production-readiness, substantially improves the assistance&#x2F;docs one gets through the IDE.<p>* 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.<p>* However, most folks don&#x27;t or won&#x27;t read docs, so additional tools will help users opt-in to strictness and quality checks that enforce best practices through the tool.<p>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.<p>I&#x27;d love your help. My Twitter DMs are open @eriwen. DM me the 1 specific thing you would change about Gradle if you could.<p>[EDIT]: Fixed the formatting of the bullet points.
评论 #16749244 未加载
评论 #16749327 未加载
评论 #16752296 未加载
评论 #16752008 未加载
评论 #16748961 未加载
lmilcinabout 7 years ago
I moved from Maven to Gradle about two years ago and I am not going to look back.<p>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.<p>My points:<p>- 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.<p>- Gradle... It&#x27;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&#x27;t need to understand it. They can, but they don&#x27;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.<p>- Maven is strictly declarative. If you can&#x27;t find a plugin you either dig up Ant or you have to write your own plugin. Not nice.<p>- In Gradle I can have almost everything declarative but I have the freedom to drop this bit of logic where it is really needed.<p>- Don&#x27;t try to make it too complex just because you start using Gradle. Great power comes with great responsibility.<p>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.
评论 #16749512 未加载
评论 #16749804 未加载
评论 #16750820 未加载
评论 #16750711 未加载
chvidabout 7 years 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.<p>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.
评论 #16749685 未加载
rhackerabout 7 years 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&#x27;s insane to think about a programming language that doesn&#x27;t have a dependency manager (even C&#x2F;C++ has Conan!).<p>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:<p>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.<p>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&#x2F;gradle plugin I ever used was 10 times harder than just bash.<p>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&#x27;s where I personally ended up liking Gradle more - because I stopped depending on Maven and Gradle to do the other kitchen sink tasks.
评论 #16748476 未加载
评论 #16749200 未加载
评论 #16748964 未加载
评论 #16749726 未加载
derrizabout 7 years ago
I can see the attraction in a build system based on a proper full featured programming language but I&#x27;ve never been tempted to try gradle because I believe the approach has a fundamental flaw. I.e. that it&#x27;s impossible for IDEs to reliably extract useful project structure from the build description.<p>Even as a 25 year vi&#x2F;vim user, I&#x27;ve succumbed to depending on IDEs more and more and I believe that any proposed build system has to easily support deep&#x2F;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.
评论 #16749080 未加载
评论 #16751283 未加载
评论 #16749363 未加载
评论 #16749344 未加载
hodgesrmabout 7 years 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&#x27;s hard to see how Gradle really improves on maven for basic Java projects.
评论 #16748720 未加载
评论 #16748705 未加载
rb808about 7 years ago
&gt; &quot;Great Flexibility. Highly customizable build. You can easily create your own task and do whatever you want.&quot;<p>Usually this is a red flag for me. People&#x27;s apps really aren&#x27;t that different, if you&#x27;re doing some weird customization its going to be a nightmare for the next guy to maintain.
评论 #16748547 未加载
评论 #16749438 未加载
evanspaabout 7 years 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&#x27;m currently doing Android development, but I&#x27;m a little embarrassed to say that I don&#x27;t really grok Gradle the way I do with Ant and Maven. I don&#x27;t have anything against Gradle. I just don&#x27;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&#x27;t been burned yet.
评论 #16753431 未加载
zmmmmmabout 7 years 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.<p>Fwiw, the need to learn groovy is a bit of a red herring because it doesn&#x27;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.
ynezzabout 7 years ago
&gt; Gradle features: Great Performance<p>Did I missed the sarcasm tone? I&#x27;ve never experienced slower build systems then those used in Java world, like Gradle for example.
评论 #16749306 未加载
评论 #16749242 未加载
评论 #16749298 未加载
评论 #16749310 未加载
ognyankulevabout 7 years ago
Reddit discussion: <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;java&#x2F;comments&#x2F;89adwf&#x2F;why_i_moved_back_from_gradle_to_maven&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;java&#x2F;comments&#x2F;89adwf&#x2F;why_i_moved_ba...</a>
dcposchabout 7 years ago
I’m surprised nobody has mentioned buck or bazel in this thread.<p>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.<p>Build times became much faster and flaky CI issues went away.<p>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.<p>Maven and Gradle are both flaky, slow, and annoying to configure, in my experience.
评论 #16756475 未加载
评论 #16752509 未加载
oftenwrongabout 7 years 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.<p>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.
tunesmithabout 7 years ago
One thing I haven&#x27;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&#x27;t do anything there. Anyone know the magic command?
评论 #16752927 未加载
sytseabout 7 years ago
We&#x27;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?
评论 #16751540 未加载
franzwongabout 7 years 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&#x27;t understand those &quot;doLast&quot; thing very well.
Traubenfuchsabout 7 years 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.
kodeninjaabout 7 years 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&#x2F;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 :(.<p>[1] <a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;11677572&#x2F;dealing-with-xerces-hell-in-java-maven" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;11677572&#x2F;dealing-with-xe...</a>
评论 #16750699 未加载
评论 #16751000 未加载
dmixabout 7 years ago
The advantages&#x2F;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&#x2F;side-effects which the latter creates.<p>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.
Steeeveabout 7 years ago
The problem with build systems is that people try to do too much with them.<p>It wouldn&#x27;t be so bad, if there was consistent, thorough documentation available, including for the various plugins that people put together and shared.<p>But where things stand it&#x27;s entirely too easy to have builds that only a few people really understand as they read through the build definitions.<p>At their heart, builds are simple. Pull in dependencies. Process templated files. Copy files. Run a test suite. Compile&#x2F;link&#x2F;etc.<p>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.<p>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 &quot;that&#x27;s easy with ant&#x2F;maven&#x2F;gradle&#x2F;buildr&#x2F;make&#x2F;etc.&quot; and can throw it together quickly along with a quick doc explaining the steps, then fantastic.<p>I think time is better spent writing software than struggling through learning a build environment.
nimrodyabout 7 years ago
Given that Gradle is here to stay... Can anyone share good resources for understanding Gradle?<p>With complex Makefiles, at least you have the sources and can try to understand the logic. With Gradle, it&#x27;s all tons of compiled java code.
dionianabout 7 years ago
As someone with extensive exprience with both, my opinion is that Kotlin will greatly tip the scales in Gradle&#x27;s favor, and I&#x27;ll probably switch to that as my preferred choice for non-scala projects
winridabout 7 years 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?<p>We have Maven builds that can take an hour and Gradle drops that down to minutes (or less than a minute).
wkoszekabout 7 years ago
I work on full-stack product, with iOS&#x2F;Android SDK element that other people integrate in their apps. Server-side with UNIX boxes: everything works always.<p>Xcode&#x2F;iOS: we published CocoaPods. It was pain to get to work reliably on laptops&#x2F;Jenkins b&#x2F;c of upgrades to Ruby, but if you lock yourself to one Ruby version, and lock the Gemfile, it&#x27;s mostly OK. At least it&#x27;s pretty obvious when&#x2F;why it doesn&#x27;t work.<p>Gradle: it&#x27;s such a mess. I don&#x27;t even know where to start. I don&#x27;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&#x27;t have the child-repo checked out because you forgot to `git submodule update --init`.<p>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&#x27;t import the project into AS. Our instructions are - after &#x27;git pull&#x27; make sure you do &#x27;git clean -dfx&#x27; and re-import the project.<p>Personally 50% of time when I start Android Studio I have some critical exception of some sort, each time from Gradle window. There&#x27;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&#x27;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&#x27;s a pain in the ass -- and `brew` doesn&#x27;t have the gradle&#x27;s we need, because they migrated to the very latest one, when in production you&#x27;d rather have older version for an extended period of support time.<p>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.<p>DSL is all right, and maybe Groovy has some unique features, but I never discovered them. This is Java language that isn&#x27;t Java, or some dialect of Java-like language aimed to make Java 3% better, but to be honest I don&#x27;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 .&#x2F;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&#x2F;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.
评论 #16752526 未加载
tomohawkabout 7 years ago
We moved to apache buildr years ago and never looked back.<p><a href="https:&#x2F;&#x2F;buildr.apache.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;buildr.apache.org&#x2F;</a>
评论 #16751520 未加载
eeccabout 7 years 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.<p>Sure, it’s an unforgiving ambition and many other systems fell trying, but it was their choice.<p>With Gradle the blame falls squarely at the feet of plugins, and you’re on your own (which has always been the case anyway)
评论 #16749258 未加载
jillesvangurpabout 7 years ago
I&#x27;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&#x27;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).<p>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&#x27;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.<p>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.<p>Speaking of Docker, packaging things up as a docker image (or rpm, or whatever), is also definitely out of scope for build files. I&#x27;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.<p>Actually, in some of my projects the whole build is a docker build. It&#x27;s great! I let it take care of downloading the jdk, gradle&#x2F;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).<p>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&#x27;s no end to it. Just don&#x27;t. Usually you are just looking at Conway&#x27;s law in action: it rarely buys you anything but misery and slow builds. KISS &amp; YAGNI.
评论 #16752170 未加载
djsumdogabout 7 years ago
I&#x27;ve used Maven, Gradle and SBT in major commercial projects. I don&#x27;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&#x27;t need to and was sooo slow.<p>I think the only good thing from Maven was the directory structure layout (src&#x2F;{main,test}&#x2F;{java,scala,groovy,resources}) which has carried on to other build system. I didn&#x27;t like that at first too, but I&#x27;ve since come around.<p>SBT does a lot of things really nicely if you&#x27;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&#x27;s a disgusting mess under there. Also the whole task dependency&#x2F;macro structure can get pretty awful when you want to run tasks with multiple configurations in one go. I don&#x27;t think it&#x27;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&#x27;s gotten better.<p>Honestly all the build systems are kinda terrible, but I&#x27;d take groovy or sbt any day over maven. I don&#x27;t see how anyone likes it. Trying to figure anything out in Maven was just miserable.
评论 #16752467 未加载
khanaabout 7 years ago
Concur. I found Gradle to be to far removed from the truth so to speak. I like Maven&#x27;s declarative xml and its promulgation of the build life-cycle. This makes a complex build easier to maintain in the long run imo.
acriveabout 7 years ago
Because you don&#x27;t know Groovy. Simple.<p>Maven it&#x27;s only in your comfort zone. Bye.
评论 #16749223 未加载
评论 #16749779 未加载