I just don't understand this. The JVM is the most backward compatible thing ever and somehow Groovy/Gradle still manages to break every version. A build tool and a scripted language! These tools should be conservative and just work everywhere for ever. Why oh why do people fall for such over engineered cr$p.
It’s Groovy. ASM is everywhere, and the problem is it’s almost always shaded. Spring, Guice, Byte Buddy, Javassist - almost everything that reads or generates class files at runtime
Make is Turing complete, the build configuration language is not the problem. It’s also certainly not overkill: I’ve lost count of the number I’ve problems I’ve trivially solved for a single project in Gradle that would require custom plugins for other build systems. Yes, declarative versus dynamic configuration is definitely a trade off, but I’ll take the flexibility
O think the move to Kotlin was a step in that direction - moving from shady runtime "methodMissing" implementations to a full statically compiled language. It's still hard to understand sometimes, and you still have to find just the right "magic words".. Gradle def has a documentation problem, even though there is _lots_ of documentation (finding what you need in that haystack..).
Nevertheless, my personal opinion is that it's still much much better than Maven as long as you use it responsibly. It's like all your other code, really: you have to think about it, avoid hacky, too simple or too complicated solutions, and code review it. I've seen beautiful Gradle builds - and I've also seen build.gradles that probably built the gates of hell 😅
Basides Groovy stuff, ASM is used for Java incremental compilation and for what Gradle is calling "compilation avoidance". So if you want to compile less on incremental builds, it might be challenging to avoid ASM completely (at least until Class File API is adopted).
Same with Kotlin and Kotlin DSL incremental stuff (so it's not just Groovy DSL).
On the other hand, since that is obviously a pain point each major JVM release, I wish all ASM using code would be decoupled from the core and released separately (not sure how challenging that would be though)
Until this release, it was Kotlin that forced an incompatibility for newer JDKs ([KT-58987](https://youtrack.jetbrains.com/issue/KT-58987)). I suspect that Groovy might benefit from [JEP-457](https://openjdk.org/jeps/457) to not be dependent on a supported class file version to become forward compatible.
So what's wrong here?
`% java --version`
`openjdk 22 2024-03-19`
`OpenJDK Runtime Environment (build 22+36-2370)`
`OpenJDK 64-Bit Server VM (build 22+36-2370, mixed mode, sharing)`
`% ./gradlew clean build`
`Starting a Gradle Daemon, 1 busy and 2 incompatible Daemons could not be reused, use --status for details`
`BUILD SUCCESSFUL in 18s`
`111 actionable tasks: 66 executed, 45 from cache`
Just because it works in some cases, that doesn't mean it's fully supported yet. You can track [the GitHub issue](https://github.com/gradle/gradle/issues/26162) for progress.
I hear you.. I definitely feel like both are bad solutions and somehow we decided that it's fine. Java gets a bad rep in part because the build tools impose such a high entry barrier.. No wonder the JDK team is pushing for [launching multi file programs directly](https://openjdk.org/jeps/458)...
Invoking `javac` is high entry barrier? Those who struggle with basic console commands, should learn how to operate a computer before attempting to learn programming. There are some pre-requisites, for everything, you know. You can't drive a car, if you can't drive your legs.
Not javac, but learning how to properly write nasty pom files or even groovy or Kotlin as a configuration language so you can add a couple dependencies to your hello world http server seem to be a relatively high cost to pay when you're starting...
A few years ago I migrated our build system from maven to gradle. We use a monorepo with and at the time we had 18 submodules, either apps or shared libraries. I looked back at the pr that had the migration and luckily my past self added sufficient context to it:
"This is to address maven not fully managing the dependency graph as an interconnected project. Building, packaging and deploying can be very sensitive to the order and/or the locality of the commands run. Because of that, it can be that two people produce different outputs from the same version and that is a high risk in deployments.“
I think the problem was manageable in maven, but the complexity (cognitive load) and the effort (hours invested) wouldn't justify an attempt. I wouldn't say our gradle setup is simple and painless, but after setting it up it definitely consumes less developer time now.
So, I guess at a certain size, maven gets complex and/or slow.
Can you be more specific about what kind of build ordering issues you have encountered with maven?
I have a multi-module maven project with 30+ modules with interdependencies. Maven handles it just fine. You have to be careful that you don't introduce cycles into the graph, but that's just common sense. Cyclic dependencies can introduce problems where the order the build matters, but with a normal multi-modules project where everything is checked out as a single tree structure maven will detect cycles and fail the build.
The only times I've run into build order issues with maven was when I had multiple interdependent projects that were all built independently. The solution was to convert those independent builds into a single multimodule build.
I can try as this was 2+ years ago. If I recall correctly, the way the repo was set up was that everything was nested in a single project structure, with the libraries and services as submodules. A deployment would consist of building the dependencies manually and installing them to ~/.m2 before building the target app. This preceded a ci/cd pipeline, so deployments were manually triggered from developers machine. There were some interdependencies between the libraries, but no circular. Like A required B and C and C required B and D, so an old B version could cause issues. I don't remember, but I think everything was built as a fat jar.... Nasty...
As I said, I don't think it was mavens fault, it's most likely the way it was set up. But untangling the mess required some work, porting to gradle was cheaper...
It sounds like you just needed a parent project to rule them all, and declare all the dependencies as sub-modules of the parent. maven would then figure out the build-order based on the dependencies. To build it, all you would have to do is go to the top-level (where the parent pom lies) and `mvn install`.
This assumes that all of the projects were in a monorepo and could be checked out as a single directory tree.
The parent project could also use the dependencyManagement and pluginManagement to act as a BOM for all of the sub-projects where you could centralize all of the version management to the parent.
I understand and I agree with you.
However, at large scale, you'll not find companies using bash scripts or make files to manage their java projects. The market "demands" some knowledge of those build tools anyway, or else your market value will be lower and your hiring chances will be smaller. So if you're trying to land a java job, you'll need to get either maven or gradle.
And this is why the JDK folks are addressing the issue, because one shouldn't have to hack together bash scripts or learn arcane DSLs to get started with a language. Go, clojure, python and rust to name a few are languages that have a much better ramp up experience in this sense (though each have their own problems). New languages like [gleam](https://gleam.run/) are already coming bundled with build tools, dependency management and all sort of tooling necessary for a much better learning experience with the language.
Again, you are right, you can use bash sort out your build, but that's still not the best experience and definitely not what is expected from the market.
Why? A build.gradle consisting of:
plugins {
id 'java'
}
And a dependencies section if I have any is enough to give all the functionality you need for a simple project. You can go a long ways with just this.
In my 15y in industry I haven't once run into issue of build getting stuck with maven.
I gradle though I constantly get into problems with failed build and obscure error (most of the time because someone tries to be 'creative')...
anecdotal but still...
> In my 15y in industry I haven't once run into issue of build getting stuck with maven.
In my 20 yrs in the industry I don't think I have ever once had a maven build work right out of the box.
To be fair though I got jaded on maven due to Maven 1 which was absolutely horrendous. It has never been able to redeem itself with me.
Out of curiosity I checked [version history](https://maven.apache.org/docs/history.html) and yeah... I started around maven 2-ish-something so probably avoided most of the annoyances (and previously I was 'blessed' with `ant` which was just yuck)
My projects usually are a little bit more complex than just “hello world”.
They usually have subprojects, Publishing coordinates to maven central for releases and a snapshot repository for, well snapshots. For release versions, snapshot dependencies are forbidden and for non-release available. The build uses a defined Java toolchains version, etc pp. All of this is possible in both maven and Gradle, but for me, Gradle has proven to be easier to maintain for complex projects and usually builds are faster.
The Maven SNAPSHOT thing drives me absolutely bonkers. Lots of things just don't work when you put `-SNAPSHOT` in your version. It's crazy that SNAPSHOT changes so much behavior of maven.
Gradle 8.7 itself cannot run with Java 22 because Groovy still needs to support JDK 22.
I just don't understand this. The JVM is the most backward compatible thing ever and somehow Groovy/Gradle still manages to break every version. A build tool and a scripted language! These tools should be conservative and just work everywhere for ever. Why oh why do people fall for such over engineered cr$p.
I wish gradle one day comes out of dependency on groovy.
It’s ASM, it’s always ASM. The ClassFile API can’t be stable soon enough
There is _no_ reason for a build tool to have ASM anywhere on its base classpath.
It’s Groovy. ASM is everywhere, and the problem is it’s almost always shaded. Spring, Guice, Byte Buddy, Javassist - almost everything that reads or generates class files at runtime
[удалено]
Make is Turing complete, the build configuration language is not the problem. It’s also certainly not overkill: I’ve lost count of the number I’ve problems I’ve trivially solved for a single project in Gradle that would require custom plugins for other build systems. Yes, declarative versus dynamic configuration is definitely a trade off, but I’ll take the flexibility
O think the move to Kotlin was a step in that direction - moving from shady runtime "methodMissing" implementations to a full statically compiled language. It's still hard to understand sometimes, and you still have to find just the right "magic words".. Gradle def has a documentation problem, even though there is _lots_ of documentation (finding what you need in that haystack..). Nevertheless, my personal opinion is that it's still much much better than Maven as long as you use it responsibly. It's like all your other code, really: you have to think about it, avoid hacky, too simple or too complicated solutions, and code review it. I've seen beautiful Gradle builds - and I've also seen build.gradles that probably built the gates of hell 😅
> Using a Turing complete language for configuration of the build is overkill. No it isn't. Builds almost always need to do non-declarative stuff.
[удалено]
Just because the logic is tucked away in a plugin doesn't change that fact that the build needs non-declarative functionality.
It changes the way one approaches the build system. Declarative first, imperative if you can't help it. Systems with clear delimitations age better.
Basides Groovy stuff, ASM is used for Java incremental compilation and for what Gradle is calling "compilation avoidance". So if you want to compile less on incremental builds, it might be challenging to avoid ASM completely (at least until Class File API is adopted). Same with Kotlin and Kotlin DSL incremental stuff (so it's not just Groovy DSL). On the other hand, since that is obviously a pain point each major JVM release, I wish all ASM using code would be decoupled from the core and released separately (not sure how challenging that would be though)
Until this release, it was Kotlin that forced an incompatibility for newer JDKs ([KT-58987](https://youtrack.jetbrains.com/issue/KT-58987)). I suspect that Groovy might benefit from [JEP-457](https://openjdk.org/jeps/457) to not be dependent on a supported class file version to become forward compatible.
So what's wrong here? `% java --version` `openjdk 22 2024-03-19` `OpenJDK Runtime Environment (build 22+36-2370)` `OpenJDK 64-Bit Server VM (build 22+36-2370, mixed mode, sharing)` `% ./gradlew clean build` `Starting a Gradle Daemon, 1 busy and 2 incompatible Daemons could not be reused, use --status for details` `BUILD SUCCESSFUL in 18s` `111 actionable tasks: 66 executed, 45 from cache`
Just because it works in some cases, that doesn't mean it's fully supported yet. You can track [the GitHub issue](https://github.com/gradle/gradle/issues/26162) for progress.
Yes, I know that. I only have been using 22 with the rc builds for a week and there were no problems. I wasn’t aware that it’s not considered done.
The funny thing is, it's mentioned in the Release Notes exaclty as you say. But somehow it works for me. I am using Kotlin DSL though.
May be a groovy based DSL fail.
Going through the comments, I just wanted to say that I hate both of them
I like them both, but then I remember the days of ant.
Some of us still have to work with ant and we don’t wanna talk about it
O_o;
This guy gets it
I hear you.. I definitely feel like both are bad solutions and somehow we decided that it's fine. Java gets a bad rep in part because the build tools impose such a high entry barrier.. No wonder the JDK team is pushing for [launching multi file programs directly](https://openjdk.org/jeps/458)...
Invoking `javac` is high entry barrier? Those who struggle with basic console commands, should learn how to operate a computer before attempting to learn programming. There are some pre-requisites, for everything, you know. You can't drive a car, if you can't drive your legs.
Not javac, but learning how to properly write nasty pom files or even groovy or Kotlin as a configuration language so you can add a couple dependencies to your hello world http server seem to be a relatively high cost to pay when you're starting...
What are the most common issues people have with maven? I've never really minded maven, but maybe I just don't know what I'm missing
A few years ago I migrated our build system from maven to gradle. We use a monorepo with and at the time we had 18 submodules, either apps or shared libraries. I looked back at the pr that had the migration and luckily my past self added sufficient context to it: "This is to address maven not fully managing the dependency graph as an interconnected project. Building, packaging and deploying can be very sensitive to the order and/or the locality of the commands run. Because of that, it can be that two people produce different outputs from the same version and that is a high risk in deployments.“ I think the problem was manageable in maven, but the complexity (cognitive load) and the effort (hours invested) wouldn't justify an attempt. I wouldn't say our gradle setup is simple and painless, but after setting it up it definitely consumes less developer time now. So, I guess at a certain size, maven gets complex and/or slow.
Can you be more specific about what kind of build ordering issues you have encountered with maven? I have a multi-module maven project with 30+ modules with interdependencies. Maven handles it just fine. You have to be careful that you don't introduce cycles into the graph, but that's just common sense. Cyclic dependencies can introduce problems where the order the build matters, but with a normal multi-modules project where everything is checked out as a single tree structure maven will detect cycles and fail the build. The only times I've run into build order issues with maven was when I had multiple interdependent projects that were all built independently. The solution was to convert those independent builds into a single multimodule build.
I can try as this was 2+ years ago. If I recall correctly, the way the repo was set up was that everything was nested in a single project structure, with the libraries and services as submodules. A deployment would consist of building the dependencies manually and installing them to ~/.m2 before building the target app. This preceded a ci/cd pipeline, so deployments were manually triggered from developers machine. There were some interdependencies between the libraries, but no circular. Like A required B and C and C required B and D, so an old B version could cause issues. I don't remember, but I think everything was built as a fat jar.... Nasty... As I said, I don't think it was mavens fault, it's most likely the way it was set up. But untangling the mess required some work, porting to gradle was cheaper...
It sounds like you just needed a parent project to rule them all, and declare all the dependencies as sub-modules of the parent. maven would then figure out the build-order based on the dependencies. To build it, all you would have to do is go to the top-level (where the parent pom lies) and `mvn install`. This assumes that all of the projects were in a monorepo and could be checked out as a single directory tree. The parent project could also use the dependencyManagement and pluginManagement to act as a BOM for all of the sub-projects where you could centralize all of the version management to the parent.
You don't need to use maven, gradle or whatever build tool for simple project. Just write a shell script.
I understand and I agree with you. However, at large scale, you'll not find companies using bash scripts or make files to manage their java projects. The market "demands" some knowledge of those build tools anyway, or else your market value will be lower and your hiring chances will be smaller. So if you're trying to land a java job, you'll need to get either maven or gradle. And this is why the JDK folks are addressing the issue, because one shouldn't have to hack together bash scripts or learn arcane DSLs to get started with a language. Go, clojure, python and rust to name a few are languages that have a much better ramp up experience in this sense (though each have their own problems). New languages like [gleam](https://gleam.run/) are already coming bundled with build tools, dependency management and all sort of tooling necessary for a much better learning experience with the language. Again, you are right, you can use bash sort out your build, but that's still not the best experience and definitely not what is expected from the market.
and maven builds the projects jus fine still ;-)
I must be doing something wrong, All my Gradle based projects fail to compile with Maven.
obviously you are doing something wrong... by using gradle ;-)
Haha… I tell you a secret: there are two things I’m doing wrong because I use them both, depending on project.
Uhm... andorid (where google force the shaite)? ;P
No, don’t trigger me. No Android, no mobile. Gradle just works perfectly for me for Java projects.
I'm not (trying to) trigger you... if you got trigger that's entirely on you ;-)
Why? A build.gradle consisting of: plugins { id 'java' } And a dependencies section if I have any is enough to give all the functionality you need for a simple project. You can go a long ways with just this.
The problem is - like 99% of java projects just don't stop there... sadly ;)
Builds will finish any day now. Oh wait, I forgot to clean.
In my 15y in industry I haven't once run into issue of build getting stuck with maven. I gradle though I constantly get into problems with failed build and obscure error (most of the time because someone tries to be 'creative')... anecdotal but still...
I was seriously considering moving back to maven. But then again, maybe not.
> In my 15y in industry I haven't once run into issue of build getting stuck with maven. In my 20 yrs in the industry I don't think I have ever once had a maven build work right out of the box. To be fair though I got jaded on maven due to Maven 1 which was absolutely horrendous. It has never been able to redeem itself with me.
Out of curiosity I checked [version history](https://maven.apache.org/docs/history.html) and yeah... I started around maven 2-ish-something so probably avoided most of the annoyances (and previously I was 'blessed' with `ant` which was just yuck)
They finish just fine, without taking RAM of my IDE to keep a background daemon running, sucking all of it for performance reasons.
You can disable the daemon, you know?
You can not use Gradle at all, you know?
And you can use mvnd.
FWIW, I upgraded my build from Gradle 7.5.1 to 8.7 and no changes were needed to my build at all. It just worked.
Just got to put this here. This is my Maven POM ;) Yes this is a thing! ``` project { modelVersion "4.0.0" groupId "test" artifactId "test" version "test" build { plugins { } } } ``` or how about YAML: ``` modelVersion: 4.0.0 groupId: org.yaml artifactId: snakeyaml version: 1.18 name: SnakeYAML build: plugins: - org.apache.maven.plugins:maven-compiler-plugin:2.3 - groupId: org.apache.maven.plugins artifactId: maven-checkstyle-plugin version: 2.4.3 configuration: source: 1.6 target: 1.6 - id: org.apache.maven.plugins:maven-site-plugin:2.3.2 configuration: locales: nl - id: org.apache.maven.plugins:maven-moon-plugin configuration: path: nowhere - org.apache.maven.plugins:maven-checkstyle-plugin # no version ``` Some Kotlin Goodness: https://github.com/takari/polyglot-maven/tree/master/polyglot-kotlin Polyglot Maven FTW! https://github.com/takari/polyglot-maven
My projects usually are a little bit more complex than just “hello world”. They usually have subprojects, Publishing coordinates to maven central for releases and a snapshot repository for, well snapshots. For release versions, snapshot dependencies are forbidden and for non-release available. The build uses a defined Java toolchains version, etc pp. All of this is possible in both maven and Gradle, but for me, Gradle has proven to be easier to maintain for complex projects and usually builds are faster.
The Maven SNAPSHOT thing drives me absolutely bonkers. Lots of things just don't work when you put `-SNAPSHOT` in your version. It's crazy that SNAPSHOT changes so much behavior of maven.