►► Getting started with Gradle just got much easier. Check out my FREE Get Going with Gradle course → learn.tomgregory.com/courses/get-going-with-gradle
Thank you for this video. Gives me a really good background to make a conscious decision on which one to pick for my new project. Off to the tutorial now :D
As a contractor, I've seen dozens of Gradle projects. Every single one of them is laid out differently and accomplish similar tasks in completely different ways. I'll stick with Maven. If you simply cannot get over Maven as XML (it is just a build file afterall, not runtime), use the Maven Polyglot option and pick from yaml, atom, closure, groovy, java, kotlin, ruby, or scala. Build tools should not themselves be mini-projects.
I watched enough of these “grade vs maven” vids but all were annoyingly missing something that helped to understand it. Couldn’t put my finger on what though. You sir, nailed it with this video. I needed the story. Thanks!
I hated gradle for a long time, because I was thinking that making it so powerful by allowing code itself to be in the build script would inevitably lead to IDEs not understanding the build process anymore. It was like ANT in disguise. I just recently looked at it again, and understood that a) IDE integration has really improved, and b) it is on you to keep the build script close to the standard, but sometimes there's just no way to do things with maven that are easy in gradle by just adding a tiny bit of code. Especially when projects get bigger, and there's stuff like company wide dependency management and CI, maven becomes a mess. So I think the time is right to switch to it.
Maven is better. Because you don't need a complex compiler to parse the build description. Which is just XML, so you can pretty fast implement your own maven. Another problem with Gradle: you can have overcomplicated build scripts.
What you despise as a "complex compiler" gives you the freedom to implement special logic quickly that are a pain to hack into a Maven build. You can't just write a plugin for everything, it's overkill. And believe it or not you can keep a Gradle build clean just by doing things the right way. It's only overcomplicated beause you don't know enough about a new tool, which is normal at first. And XML is ugly, verbose, not easy to read.
Also you're missing out on a great power of Gradle that Maven still doesn't get: that today we got big projects to build, and parallel building, up-to-date checks, and build caching are king.
How do you implement something like this in a few minutes in gradle? mvn versions:use-dep-version -Dincludes=$GROUP_ID:$ARTIFACT_ID -DdepVersion=$DEP_VERSION Gradle more looks like a hipe tool from JS world Maven has simple and strict structure in other hand you have gradle spaghetti where anyone write as he want and it is really hard to automatize and understand
That would be build.gradle, the Groovy build script. Or build.gradle.kts, the Kotlin build script. You can choose either language to write your build script.
Yes, it is very apparent that you love Gradle, but the does not make Gradle better than Maven. There are still many characteristics of Maven that will always be better than Gradle. For example, quality. Gradle documentation and diagnostics are terrible. Granted your videos on Gradle are very high quality, but wrt Gradle, this is the exception and not the rule.
Exactly. And the author said the only reasons could ever prevent you from switching from Maven to Gradle is the lack of time? That's the biggest Gradle lie. Author chose to explicitly define 2 categories that won't switch as if he wrote a book about it? Give me a break. Let me give you Calegory 3: Cold-blooded realists. Why do projects switch to Gradle? Because Maven is not perfect and people were hoping for a breakthrough with Gradle. By the time they realized it solved some problems but created whole new ones, it was too late to switch back. That's why so many projects switched to Gradle nearly the same time and that sole fact fools everyone else that it is objectively better when it's just NOT!
It is still not really possible to build rcp projects with gradle, you have to use tycho on maven. It's really a pain as it is slow and cumbersome in contrast to our gradle builds.
@@TomGregoryTech Oh nice, I just started my first tech job. I think understanding dev-ops concepts is the hardest part for me right now. The coding and building applications is the easy part. I'll definitely follow your channel, we use lots of the tech you cover at work!
►► Getting started with Gradle just got much easier. Check out my FREE Get Going with Gradle course → learn.tomgregory.com/courses/get-going-with-gradle
Thank you for this video. Gives me a really good background to make a conscious decision on which one to pick for my new project. Off to the tutorial now :D
As a contractor, I've seen dozens of Gradle projects. Every single one of them is laid out differently and accomplish similar tasks in completely different ways. I'll stick with Maven. If you simply cannot get over Maven as XML (it is just a build file afterall, not runtime), use the Maven Polyglot option and pick from yaml, atom, closure, groovy, java, kotlin, ruby, or scala. Build tools should not themselves be mini-projects.
I watched enough of these “grade vs maven” vids but all were annoyingly missing something that helped to understand it. Couldn’t put my finger on what though.
You sir, nailed it with this video. I needed the story. Thanks!
Thanks for going to depths of the origins of Gradle...
I hated gradle for a long time, because I was thinking that making it so powerful by allowing code itself to be in the build script would inevitably lead to IDEs not understanding the build process anymore. It was like ANT in disguise. I just recently looked at it again, and understood that a) IDE integration has really improved, and b) it is on you to keep the build script close to the standard, but sometimes there's just no way to do things with maven that are easy in gradle by just adding a tiny bit of code. Especially when projects get bigger, and there's stuff like company wide dependency management and CI, maven becomes a mess. So I think the time is right to switch to it.
Hello Tom. It was a very informative video.
Maven
It is nice. It is not boring.
This video disinform the audience - Maven pom file could be written in any format, yaml, json, or even Java, Scala or Kotlin
Maven is better. Because you don't need a complex compiler to parse the build description. Which is just XML, so you can pretty fast implement your own maven.
Another problem with Gradle: you can have overcomplicated build scripts.
What you despise as a "complex compiler" gives you the freedom to implement special logic quickly that are a pain to hack into a Maven build. You can't just write a plugin for everything, it's overkill. And believe it or not you can keep a Gradle build clean just by doing things the right way. It's only overcomplicated beause you don't know enough about a new tool, which is normal at first. And XML is ugly, verbose, not easy to read.
Also you're missing out on a great power of Gradle that Maven still doesn't get: that today we got big projects to build, and parallel building, up-to-date checks, and build caching are king.
@@SirWolf2018 Hard agree on the xml part, it is horrificly ugly and hard to read, thats probably the most dreaded part of android development.
How do you implement something like this in a few minutes in gradle?
mvn versions:use-dep-version -Dincludes=$GROUP_ID:$ARTIFACT_ID -DdepVersion=$DEP_VERSION
Gradle more looks like a hipe tool from JS world
Maven has simple and strict structure in other hand you have gradle spaghetti where anyone write as he want and it is really hard to automatize and understand
Maven has pom.xml. What is gradle's equivalent?
That would be build.gradle, the Groovy build script. Or build.gradle.kts, the Kotlin build script.
You can choose either language to write your build script.
Yes, it is very apparent that you love Gradle, but the does not make Gradle better than Maven. There are still many characteristics of Maven that will always be better than Gradle. For example, quality. Gradle documentation and diagnostics are terrible. Granted your videos on Gradle are very high quality, but wrt Gradle, this is the exception and not the rule.
Exactly. And the author said the only reasons could ever prevent you from switching from Maven to Gradle is the lack of time? That's the biggest Gradle lie. Author chose to explicitly define 2 categories that won't switch as if he wrote a book about it? Give me a break. Let me give you Calegory 3: Cold-blooded realists.
Why do projects switch to Gradle? Because Maven is not perfect and people were hoping for a breakthrough with Gradle. By the time they realized it solved some problems but created whole new ones, it was too late to switch back. That's why so many projects switched to Gradle nearly the same time and that sole fact fools everyone else that it is objectively better when it's just NOT!
From the cradle to the grave #tupac.
~./gradlew
It is still not really possible to build rcp projects with gradle, you have to use tycho on maven. It's really a pain as it is slow and cumbersome in contrast to our gradle builds.
Is this a dev ops channel?
Yes, most of the content covers devops topics.
@@TomGregoryTech Oh nice, I just started my first tech job. I think understanding dev-ops concepts is the hardest part for me right now. The coding and building applications is the easy part. I'll definitely follow your channel, we use lots of the tech you cover at work!