6 ms·

Why Move from Gradle to Maven

• nanagojo 6y ago
  Strange, gradle is just way faster in my use cases. Maven has always been a pain with regards to speed with handling dependencies.
  • Jakobeha 6y ago
    Yeah, this article is really not convincing. I've used both gradle and maven and IMO gradle is better in practically every way.
    • jimbob45 6y ago
      Is there a benefit to using either over MSBuild?
      • mobilio 6y ago
        Or Make? CMake?
      • escardin 6y ago
        I assume if you are using MSBuild you're building .net or otherwise using visual studio. If you want to build these projects with gradle or maven you still have to invoke MSBuild in my experience. It's not strictly necessary AFAIK, but you'd be giving up a lot of what visual studio offers you for little in return. In general, if you aren't already using a JVM language, there is not a whole lot of reason to use maven or gradle. Pretty much every language has equivalent native build tooling that you should be using instead. If you are using a JVM language, even for part of your build process, then both can be used as the primary build tool and invoke the build tooling of the other ecosystems as needed. This is most useful when you have a native component that you are using from the JVM. I have in the past used gradle to build the native C++ components for apps, but in general it reached out to msbuild on windows, and make files on linux. I've used gradle it to invoke npm commands to build the frontend component of a WAR java webapp.
  • johnisgood 6y ago
    If Gradle is fast in comparison to Maven, then I cannot begin to imagine how slow Maven is. A build system that has to spawn a daemon to speed up the process is a pretty shitty one. It takes about 2-3 minutes to do that for me, and still it takes 30 seconds to build my program which is not even that huge.
    • elygre 6y ago
      Are you saying that it takes 2-3 minutes to start the grade daemon? That sounds weird.
      • johnisgood 6y ago
        Yeah, it does. I have 8 GB memory, and an Intel G3xxx CPU. I am baffled by how slow it is. For people who do not believe me, I am willing to record it, but I have to go to sleep now. :/
        • antonyh 6y ago
          That's been my experience of Gradle too. It's always been slower than Maven for me. In any case, 90% of build time is unit tests for the projects I've worked on, so switching tools offer minimal benefit in that regard.
    • winrid 6y ago
      Something is wrong with your setup methinks. Gradle daemon starts in a second or so for me on the two Java projects on this machine (around 20koc each) and like one second build times...
      • johnisgood 6y ago
        What could possibly be wrong with the setup though that would cause it? I have a couple of dependencies, including libGDX, artemis-odb, and kotlin-stdlib-jdk8. I posted it in another comment, but I am willing to record it when my time allows. It is quite baffling. I never encountered such slow compilation times even though I compiled some C++ projects before.
  • throwaway189262 6y ago
    There's a maven daemon project now that closes most of the speed gap for my projects
• rektide 6y ago
  super short post, on a topic that seems not super relevant to many. but i dig it. i dig it a lot. languages are a pain in the butt. you can do anything with languages. so can everyone else using the language. it's actually quite nice having constraints. having a uniform model, having dead inert data. everyone using the same machine, the same mechanisms. maven'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's ordered simplicity, in it's learnability, in it's familiarity. 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'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's code, other people's endless variegated opinions, all unlike, all foreign. that said, maven leaves extreme power in the hands of it's plugins. plugins do a lot. i spent years combing through docs, & looking at different project builds, & 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 & special were actually quite short, often rather simple manipulators of a couple of files. it took diving in to see how elegant & simple maven & it's vast sea of plugins really (often) were. [1] https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html https://maven.apache.org/guides/introduction/introduction-to...
  • michaelcampbell 6y ago
    Yeah, I'm a big fan of Groovy (and Kotlin, though I know it less), but what bugs me about Gradle is, at least when I last used it which to be fair is some years, is that it solves 50% out of the box. Maven was closer to 85%. The Gradle manual started with, "here's how you write your own tasks!" I don't want to write my own; I want to know how if I need to, but you're saying I need to right off the bat. Maybe that was an issue with the manual vs. the tool, but if the build tool needs documentation to tell me how to build a build tool on chapter one...
    • 6y ago
• cutchin 6y ago
  This is an oddly unconvincing little write-up. Firstly, learning gradle doesn't mean you are learning Maven simply because most dependencies use pom files for their metadata. I just means there's a little XML document embedded in your dependencies that 99% of developers never pay attention to, whether they're using Maven or ant or any other build tool. It's entirely irrelevant. Secondly, Gradle does not require you to learn Groovy. Use Kotlin if that's your thing - I get the impression that's the preferred DSL nowadays anyways. Sadly I think those are the only two reasons really presented. Neither is especially convincing. IDE support seems just fine for both platforms. 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'm sure either system will get the job done.
  • cutchin 6y ago
    Since I mentioned Gradle aggravations, I'll share a couple: 1. Bizarre and inscrutable syntax. They say things like "build scripts are just Groovy code", but some things, like how you define sourcesets or configurations, don't look like anything that should parse, much less compile, in any C-like language. They're doing some fancy meta-programming stuff behind the scenes to keep things light and simple, but it really isolates (and possibly alienates) developers from exactly what's happening under the covers. The Kotlin DSL seems to help make it more clear what's going on, but I haven't used it much yet. Having used Gradle for years, it is strangely off-putting how unsure I often am about whether to put a colon in a particular place or a comma, or if something should be in parenthesis. 2. If you want to do anything beyond what's documented you can get into a bit of trouble, and if you find answers more than a couple of years old there's a good chance they often won't work. Making sense of the DSL documentation is sometimes a little tricky. Beyond that, I would dare say it's the least awful option for building for the JVM. Their documentation is very comprehensive, it's fast, they are very fair about providing deprecation warnings before features are removed. It's rare I find a case where I'd like to use some external library that has a Maven plugin but no Gradle support.
    • imtringued 6y ago
• voodootrucker 6y ago
  For practical reasons, I have to admit gradle is better than maven. Gradle is least bad. However, I do have to say turing completeness in a build system is an anti-goal for me. You shouldn't have to guess if your build will halt. I've seen terrible things done in builds, and most importantly, static analysis is the point of these systems... it's what makes IDEs able to work. 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... 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's crazy hard to know what to type. And god forbid you have to debug it. I've added for loops to print out every variable, and for god sakes I've even had to attach a debugger to my build to figure out what it's doing. That's just nuts. [edit] And finally, let's not ignore that fact that groovy tries very hard with it's closure syntax to look like JSON, so many developers paste in code from stack overflow and think it's actually configuration. (I actually kind of like that for other uses of groovy). [edit2] apparently they know it's so bad gradle (the "gr" comes from "groovy") now uses kotlin for it's own build scripts (like on their github repo). If anyone's done gradle with kotlin I'd love to know if it actually helps.
  • manyxcxi 6y ago
    Yes. The Kotlin DSL helps immensely- probably mostly because the IDE can actually autocomplete the various closures and attributes. A few things get a bit more verbose/ugly but mostly it’s similar.
    • voodootrucker 6y ago
      Thanks! If the build model is statically analyzable I can see how that would help a lot. I'll generate my next project with gradle/kotlin and report back :)
  • legerdemain 6y ago
    You can download the source build of Gradle and get autocomplete for the Groovy DSL as well. Just change `distributionUrl` to the `-all` build of Gradle in your project's gradle-wrapper.properties.
• deleted 6y ago
  [deleted]
• simon04 6y ago
  Is it denotive that nobody has mentioned Bazel so far? It supports building Java applications as well: https://docs.bazel.build/versions/master/tutorial/java.html https://docs.bazel.build/versions/master/tutorial/java.html
  • The_rationalist 6y ago
    https://blog.gradle.org/gradle-vs-bazel-jvm#:~:text=Both%20Gradle%20and%20Bazel%20provide%20support%20for%20dependency%20management%20workflows,is%20required%20to%20use%20it https://blog.gradle.org/gradle-vs-bazel-jvm#:~:text=Both%20G....
• anothernewdude 6y ago
  > First off, you cannot not learn Maven I can think of a way to make that happen.
• ajnin 6y 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. 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. Here's my opinion about Gradle : 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. 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. 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.
  • antonyh 6y ago
    I like XML. It tells me when I've forgotten a value, like 'version'. I still don't get why people rail against a machine-and-human-readable format that isn't space-sensitive, can be easily validated, and can be processed by virtually any language. Sure it's verbose, but it's also robust.
• antonyh 6y ago
  What I don'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's countless ways to build custom jars.
• antonyh 6y ago
  Has Gradle finally got an equivalent to parent pom? It'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't do this.
• setheron 6y ago
  I love the simplicity of Maven and declarative build tools vs imperative. The problem is Maven has a huge legacy code base and sees very little improvement. Its ability to concurrently build modules is flawed and it doesn't have incremental compilation support. 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. Btw Maven can now read POM file in other languages than XML like Groovy & Kotlin
• sischoel 6y 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. Anyone has some experience with that?
• AtlasBarfed 6y ago
  Gradle: Inexcusable API churn and arguably worse spaghetti builds than Ant ever had, with loads of undocumented "magic". Maven: BACK TO XML? Awful. Maven's common directory structure is about the only positive it brought, and I still wince at "src/main". They should have flattened more. Also the pedantic "coordinates" or "artifacts". These are jar names and versions, people, not some cyber virtual reality. Maven, while it did push forward on pulling dependencies from repositories, didn't separate the dependency download from the code build, so build reproducibility became dependent on the repository access/status/completeness.