It was sarcasm. I recommended it to @alex22 since he obviously deserves it. I am a fan of Gradle. I like to criticize it from time to time since there are problems (for example plugin management should be completely redone). Still, the reliable build system is one of the cornerstones of the Kotlin ecosystem. And even if it is a little bit more complicated, the reliability is much more important…
1 Like
Poe’s Law strikes again… 
Mind you, if I’d said:
…then I wouldn’t have been sure whether I was being sarcastic or not! Yes, a reliable build system is vital — but Gradle will have to make up for a lot of previous pain before I’ll call it ‘reliable’.
1 Like
In my experience there are problems with gradle, but they usually begin in places, other build systems just do not reach.
7 Likes
Well there is the point that it is hard to learn for newcomers. Everything that requires more than just a dependency block can get quite complicate to figure out. The documentation is quite good (in my experience) but since gradle is so versitile it’s still sometimes hard to find what you need. Also lots of gradle plugins and example build scripts are written in goovy and tbh groovy is terrible to read in a complicated system.
Other than that I can’t complain about gradle.
Most of the Gradle files are there for 2 purposes:
- Other developers do not have to manually download Gradle. The wrapper script will do that for them.
- Everybody uses the same Gradle version to build the project.
gradle.properties is there so you can do local customization (so do not commit it) of the build.
Are you seriously complaining about .gitattributes?
2 Likes
Only thing I miss from, say package.json or maven to some degree, is IDE code completion/suggestion on version or package information… Unless I have missed some setting/plugin in intellij (please let me know!), I find myself going to the web to find version info on packages more often than when using maven/pom.xml. I guess providing version info in Gradle is more flexible so thus harder to create code assist functionality.
Other than that, much prefer Gradle
@ccfnz Version completion is working in groovy gradle. It should work for kts soon if not already.
1 Like
Just curious: why did you guys pick Gradle over Maven?
1 Like
Any coding/logic in Maven is very quickly an incomprehensible mess of xml tags. Gradle has more advanced capabilities while still being able to consume maven artefacts.
Also maven is the standard for most java applications. Kotlin is build on the java ecosystem so supporting maven is necessary to make it easier for people and teams to switch.
Gradle is in my experience more often an incomprehensible mess 
Yes, but why pick Gradle?
Gradle is more flexible and has a more advanced model for building software.
Maven basically is a fixed number of steps, and at each step you can run a number of plugin goals. The goals are usually “dumb”, i.e. they always do their job even if nothing in their inputs has changed.
Gradle has more of a data flow model. You chain multiple transformers (tasks) in a graph to get the outputs that you want. Gradle only runs a task if it determines that the inputs of the task have changed. (For this to work you have to declare the inputs and outputs properly. There are also tasks that are not transformations (e.g. publish to a repository), but Gradle uses the name task for everything.)
I think Gradle provides the flexibility that is needed for having Java & Kotlin in the same module being able to call each other, multi platform, etc.
3 Likes
I understand Gradle is more flexible. Most builds however do not require ‘smart’ build scripts. Usually all the build should do is gather dependencies, compile and package.
I think Gradle provides the flexibility that is needed for having Java & Kotlin in the same module being able to call each other, multi platform, etc.
For multiplatform I can image it having it’s use, but just Java&Kotlin being in the same module works great in Maven.
Oh well, we’ll see what the future brings.
I found gradle (kts) to be pretty easy for basic projects as well. But I agree, finding help for more complex cases is sometimes difficult. And I wish it would start faster too. But once it has its server loaded, I find it pretty fast too, especially since it recompiles only what’s needed. I also like that i can build js/npm projects as well as my kotlin/jvm projects. So everything builds perfectly in one command.
2 Likes
Excuse me if I disagree. I have been developing build/ci stuff for 10 years now in a company with many different projects. We startet with Ant, soon tried Maven but only were glad when we discovered Gradle 6 years ago.
From my experience there is no real world project, that does not have at least some tiny special bit that is outside of the Maven “convention over configuration” world.
Gradle allows us to use conventions AND easily extend or adjust if necessary.
And yes, of course, I have had many headaches with Gradle, too. But thats because things are sometimes complex… And in the end I always was able to solve all these problems because Gradle lets me do so! It gives me all the power to reconfigure everything if necessary.
I can totally agree to what others here said before: it surely can improve (which it continuously does) but it’s the best out there!
1 Like
This is an old topic, but for me Maven/Gradle were simply one of the biggest milestones regarding the quality of day-to-day software engineering in my life. And I don’t exaggerate here. Typical scenario:
- A new person in the team.
- Install any fresh linux, Windows or other OS.
- Install Java.
- Download sources of the project - (almost) only text files.
-
./gradlew buildor even./gradlew runfor executable projects - just works in 99% of cases. If project is unmainained for 5 years, it should be still successful in 95% of cases.
I don’t know if there were any tools like this before, but they were created in times when typical scenario was something like:
- Use a specific IDE that the project creator use.
- Ahh, and in the same/similar version.
- Download 200MB of sources, because they contain some libraries.
- Maybe install some other dependencies.
- Maybe run some commands.
- If you are lucky, it could work.
Maven/Gradle changed everything. They were the same for building as docker/containers were for deploying - easy to use solution that just works, without a need to have expert knowledge about the project, without a need to read 20 pages of README file.
Some years passed, I totally got used to the fact that building “just works” and then I needed to do something with a very simple project in nodejs. I didn’t have the knowledge about it, I didn’t have any pre-made setup to use it. It took me half a day to even build this simple project. I would say this is a terrible user experience. I don’t know if it improved with time, but I’m afraid it might not, as I believe it still does not use a “wrapper script”, so it is highly dependent on the local environment and the knowledge about how to setup it correctly. Gradle is not.
Also, I don’t really understand complain about not having simple “install” command in Gradle. I just need to build/run some project. Why do I have to install anything in the first place? I don’t want to.
And regarding Gradle’s complexity: basic Gradle project is just a build.gradle.kts with plugins { java } in it. This is all that’s needed to have a working project that compiles to a Java library. Anything more is just to add some optional features. gradle init is verbose, it creates files to help you start, but you can remove most of them if you don’t need them.
5 Likes
The problem is that Java comes from very distant past, some 20 years ago. Back then, people didn’t realize that package managers should exist. It wasn’t even an idea. So a lot of these backwards thinking is baked into Java and its tooling. Well, Kotlin as a Java successor builds upon this foundation.
Anyone coming from a modern language with a modern package manager such as JavaScript will be aghast by how terrible Gradle is. But you have to take into account the history to understand the context.
History has nothing to do with how Maven/Gradle was designed. Situation of Java and JavaScript is actually very similar. They both were created 20+ years ago (in exactly the same year), they both do not provide any package manager and they both have package managers as external tools: yarn, npm, etc. for JS and Maven, Gradle, Ivy for Java/Kotlin.
I guess it would be even possible to port npm or yarn to Java with almost the same usage specifics, but nobody would use it, because there is Maven/Gradle.
2 Likes
Kotlin was one of my favorite languages, until I gave up on having any hope of ever being able to figure out Gradle. It’s not for a lack of trying to educating myself or for a lack of intelligence, I have mostly no issues when using npm, yarn, composer, or nuget. But Gradle gives me nothing but problems. I was working on a personal project and only got so far with it because I couldn’t get other libraries to be included in my project.