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 Move from Gradle to Maven

31 pointsby foxgroverover 4 years ago

12 comments

cutchinover 4 years ago
This is an oddly unconvincing little write-up.<p>Firstly, learning gradle doesn&#x27;t mean you are learning Maven simply because most dependencies use pom files for their metadata. I just means there&#x27;s a little XML document embedded in your dependencies that 99% of developers never pay attention to, whether they&#x27;re using Maven or ant or any other build tool. It&#x27;s entirely irrelevant.<p>Secondly, Gradle does not require you to learn Groovy. Use Kotlin if that&#x27;s your thing - I get the impression that&#x27;s the preferred DSL nowadays anyways.<p>Sadly I think those are the only two reasons really presented. Neither is especially convincing. IDE support seems just fine for both platforms.<p>I actually _like_ Gradle and I think I could come up with a longer list of things about it that aggravate me. But either way, use whatever build system you want, and if, as stated, their projects have fairly humble requirements build-wise, I&#x27;m sure either system will get the job done.
评论 #25654332 未加载
评论 #25656603 未加载
voodootruckerover 4 years ago
For practical reasons, I have to admit gradle is better than maven. Gradle is least bad.<p>However, I do have to say turing completeness in a build system is an anti-goal for me. You shouldn&#x27;t have to guess if your build will halt. I&#x27;ve seen terrible things done in builds, and most importantly, static analysis is the point of these systems... it&#x27;s what makes IDEs able to work.<p>From what I understand the turing complete code in gradle merely builds the model, which the IDE (or gradle) can then use to run the build, but still...<p>Finally, if you do have to use a turing complete language, it sure would be nice to use one with static types. I know groovy syntax reasonably well, but without auto-complete on my build scripts (less my project), except at run time it&#x27;s crazy hard to know what to type. And god forbid you have to debug it. I&#x27;ve added for loops to print out every variable, and for god sakes I&#x27;ve even had to attach a debugger <i>to my build</i> to figure out what it&#x27;s doing. That&#x27;s just nuts.<p>[edit] And finally, let&#x27;s not ignore that fact that groovy tries very hard with it&#x27;s closure syntax to <i>look like</i> JSON, so many developers paste in code from stack overflow and think it&#x27;s actually configuration. (I actually kind of like that for other uses of groovy).<p>[edit2] apparently they know it&#x27;s so bad gradle (the &quot;gr&quot; comes from &quot;groovy&quot;) now uses kotlin for it&#x27;s own build scripts (like on their github repo). If anyone&#x27;s done gradle with kotlin I&#x27;d love to know if it actually helps.
评论 #25654682 未加载
评论 #25655954 未加载
ajninover 4 years ago
Before Maven, there was Ant. Ant is a fancy Makefile written in XML that makes it very very easy to write build scripts that are not reproducible and rely on a particular structure and set of tools on the computer of the person that wrote the build file. At some point people realized the madness and wrote a new build tool that would only use declarative syntax, and would provide reproducible, contained build bliss. And lo and behold Maven came to be.<p>Later XML came into disfavor, as things do, and thus by association Maven as it uses XML. So they created Gradle, a tool deemed superior by the mere virtue of using a Groovy DSL instead of XML.<p>Here&#x27;s my opinion about Gradle :<p>1 - the syntax is poor. Merely not using XML does not imply that it is fun to write Gradle build files. XML is verbose but very well specified so when you need to write some configuration it is a bit tedious but all in all very easy. On the other end Gradle uses a custom DSL that is poorly documented. Usually the best documentation there is are example files, so it can be very hard to figure out what to do in uncommon cases.<p>2 - plugins can extend the DSL. That means there is no single document to learn to know how to write Gradle build files, you also need to learn the DSL for the plugins you use. Maven developers went as far as specifying a standard plugin documentation format so that when you need to look for the syntax for a particular plugin you can do so fairly easily. Not so with Gradle, documentation quality is inconsistent and hard to find. The Android plugin seems especially bad in that regard.<p>3 - it killed the dream of declarative builds. Gradle allows to run Ant files directly and is simply Groovy under the hood so build scripts can quickly become ad hoc messes. Not what I call progress.
评论 #25658819 未加载
rektideover 4 years ago
super short post, on a topic that seems not super relevant to many.<p>but i dig it. i dig it a lot.<p>languages are a pain in the butt. you can do anything with languages. so can everyone else using the language.<p>it&#x27;s actually quite nice having constraints. having a uniform model, having dead inert data. everyone using the same machine, the same mechanisms. maven&#x27;s lifecycle[1], the steps of a build, being well defined, in order, serving as a backbone for plugins to extend, is powerful in it&#x27;s ordered simplicity, in it&#x27;s learnability, in it&#x27;s familiarity.<p>i have barely touched jvm in the last decade, but even a decade ago, i think the lessons here are really killer, really key, really insightful. it&#x27;s not apparent exactly how this applies to a broader scope of computing, but i think there are some really important lessons we still need to grapple with. that languages offer too much freedom. that being able to do anything ends up with everyone doing something different, a proliferation of hell as other people&#x27;s code, other people&#x27;s endless variegated opinions, all unlike, all foreign.<p>that said, maven leaves extreme power in the hands of it&#x27;s plugins. plugins do a lot. i spent years combing through docs, &amp; looking at different project builds, &amp; maven retained a vast aura of mystery, left endless questions abound. i resisted going further, understanding what plugins really were, looking at what they were doing. once i started reading their sources, i was quite surprised to find many of the plugins i thought powerful &amp; special were actually quite short, often rather simple manipulators of a couple of files. it took diving in to see how elegant &amp; simple maven &amp; it&#x27;s vast sea of plugins really (often) were.<p>[1] <a href="https:&#x2F;&#x2F;maven.apache.org&#x2F;guides&#x2F;introduction&#x2F;introduction-to-the-lifecycle.html" rel="nofollow">https:&#x2F;&#x2F;maven.apache.org&#x2F;guides&#x2F;introduction&#x2F;introduction-to...</a>
评论 #25654276 未加载
nanagojoover 4 years ago
Strange, gradle is just way faster in my use cases. Maven has always been a pain with regards to speed with handling dependencies.
评论 #25654837 未加载
评论 #25654023 未加载
评论 #25656562 未加载
setheronover 4 years ago
I love the simplicity of Maven and declarative build tools vs imperative.<p>The problem is Maven has a huge legacy code base and sees very little improvement.<p>Its ability to concurrently build modules is flawed and it doesn&#x27;t have incremental compilation support.<p>There is an opportunity to build a new Maven (Maven 4) from scratch with some newer principles but adhering to most of the XML format.<p>Btw Maven can now read POM file in other languages than XML like Groovy &amp; Kotlin
AtlasBarfedover 4 years ago
Gradle: Inexcusable API churn and arguably worse spaghetti builds than Ant ever had, with loads of undocumented &quot;magic&quot;.<p>Maven: BACK TO XML? Awful. Maven&#x27;s common directory structure is about the only positive it brought, and I still wince at &quot;src&#x2F;main&quot;. They should have flattened more. Also the pedantic &quot;coordinates&quot; or &quot;artifacts&quot;. These are jar names and versions, people, not some cyber virtual reality.<p>Maven, while it did push forward on pulling dependencies from repositories, didn&#x27;t separate the dependency download from the code build, so build reproducibility became dependent on the repository access&#x2F;status&#x2F;completeness.
sischoelover 4 years ago
There are some claims that Gradle builds way faster than maven. I personally witnessed at my last job (usual Spring Boot, Hibernate stack), that the builds were indeed way faster after migrating to Gradle, but then the Maven configuration had quite some years behind it, so it could also be possible that it was not setup optimal.<p>Anyone has some experience with that?
simon04over 4 years ago
Is it denotive that nobody has mentioned Bazel so far? It supports building Java applications as well:<p><a href="https:&#x2F;&#x2F;docs.bazel.build&#x2F;versions&#x2F;master&#x2F;tutorial&#x2F;java.html" rel="nofollow">https:&#x2F;&#x2F;docs.bazel.build&#x2F;versions&#x2F;master&#x2F;tutorial&#x2F;java.html</a>
评论 #25660525 未加载
antonyhover 4 years ago
Has Gradle finally got an equivalent to parent pom? It&#x27;s such a vital feature, to be able to set dependency versions and plugins up to use on all child projects and publish into a repo. Last time I looked, Gradle couldn&#x27;t do this.
antonyhover 4 years ago
What I don&#x27;t get is the exception: this could be handled with a custom maven plugin (as an extreme way) or a wedge of inline script in the pom.xml (sloppy and maybe not so portable). Or the Assembly plugin. There&#x27;s countless ways to build custom jars.
anothernewdudeover 4 years ago
&gt; First off, you cannot not learn Maven<p>I can think of a way to make that happen.