Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
This very much lines up with my experience. A long time ago I wrote a Maven plugin[0] and it got absolutely nowhere because after everything you describe (setting up a repo, learning the Maven API, which is one of those APIs that has a lot of metaphoric semantic constructs), distributing it involved getting it into Maven Central by which point I was had run out of time/mental bandwidth and never made it happen. Compare with Grade, I would have just coded it up in Groovy, a language I thoroughly enjoy, right there in setup. There's a lot I don't like about Gradle, but there's a lot it has going for it, too.
[0] https://github.com/dminkovsky/babel-relay-maven-plugin
Being new to Gradle, I used to run into this same issue. In one of the projects I use, I happened to find this comment, in github, which helped me fix the issue https://github.com/quarkusio/quarkus/issues/10454#issuecomme...
So increasing the default max heap size of the gradle build helped fix the issue https://github.com/quarkusio/quarkus/pull/10508/files.
I forked a project [1] in 2015 to remove Gradle, and it then quickly subsumed the original project, remaining under active development to this day.
There were other reasons, but de-gradling was one of the main motivations for my fork, and among the first of the major changes I made. The project is an implementation of an API which was discontinued by the original developers, but initially was built using Maven.
After switching from Gradle (which the project switched to in 2014) back to Maven, build times significantly decreased and development became much more pleasant. I found Gradle to be like a speed bump slowing down development, and reverting back to Maven was like a breath of fresh air. Simple, straightforward, and fast. Maven may not be perfect, but it does the job well.
[1] An open source Bukkit server implementation, https://github.com/GlowstoneMC/Glowstone -> http://github.com/GlowstonePlusPlus/GlowstonePlusPlus
> Now “obviously” the answer is that we should have pegged the version of gradle required to use the script
My first step with either gradle or maven is to install the wrapper generator, which has this effect. After adding the wrapper you invoke it via ./gradlew or ./mvnw in the project doirectory.
It’s not perfect - especially in terms of IDE support - but it’s crucial to at least keeping your CLI builds consistent across team members and in automation.
gradle wrapper: https://docs.gradle.org/current/userguide/gradle_wrapper.htm...
maven wrapper: https://github.com/takari/maven-wrapper
One thing that helped me a lot is to decompile the compiled build script classes with e.g. JADX [1] to see how my code gets turned into Java, since that is what I already knew.
That was my "Ah-ha!" moment in using Gradle.
[1] https://github.com/skylot/jadx
You could have a look at something like Geb - this is a completely random class I picked:
https://github.com/geb/geb/blob/master/module/geb-core/src/m...
So it looks mostly like Java, its just making use of Groovy's niceties and more powerful constructs in various parts to make the coding nicer.