Why Move from Gradle to Maven
blog.astradot.com
Why Move from Gradle to Maven
1–10 of 44 posts
Re: Why Move from Gradle to Maven
#2Strange, gradle is just way faster in my use cases. Maven has always been a pain with regards to speed with handling dependencies.
Re: Why Move from Gradle to Maven
#3Strange, gradle is just way faster in my use cases. Maven has always been a pain with regards to speed with handling dependencies.
Yeah, this article is really not convincing. I've used both gradle and maven and IMO gradle is better in practically every way.
Re: Why Move from Gradle to Maven
#4Strange, gradle is just way faster in my use cases. Maven has always been a pain with regards to speed with handling dependencies.
Yeah, this article is really not convincing. I've used both gradle and maven and IMO gradle is better in practically every way.
Is there a benefit to using either over MSBuild?
Re: Why Move from Gradle to Maven
#5super 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...
Re: Why Move from Gradle to Maven
#6Re: Why Move from Gradle to Maven
#7Earlier quoted context omitted.
Yeah, this article is really not convincing. I've used both gradle and maven and IMO gradle is better in practically every way.
Is there a benefit to using either over MSBuild?
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.
Re: Why Move from Gradle to Maven
#8This 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.
Re: Why Move from Gradle to Maven
#9super 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,…
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...
Re: Why Move from Gradle to Maven
#10This 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 t…
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.