Gradle 3.0 Release Notes(docs.gradle.org)
docs.gradle.org
Gradle 3.0 Release Notes
https://docs.gradle.org/current/release-notes
38 comments
I think you mean "Kotlin instead of Groovy"
He actually meant "Kotlin instead of Apache Groovy". Groovy joined the Apache Software Foundation last November (2015), and its name should be qualified with the "Apache" brand on first use in a new context such as a webpage. Groovy joined the ASF after the 6 developers working on it and Grails were retrenched by VMware in March last year, and they couldn't find any other business to support their work on Groovy.
I did, yep. Thanks!
My shop relies on an Ant script for our builds. We still manage our dependencies by hand and package everything ourselves, but we've got a system that works.
We're (slowly) working on doing an upgrade to all our infrastructure, so one of the things we've examined is moving from Ant to Maven. While there's a lot of people that've expressed dissatisfaction with it, you can't ignore the fact that tutorials, setup instructions and such seemingly to a one are written with a pom.xml in mind.
So to that end, I wonder what place Gradle has. I've played with it a bit outside of this project and it seems nice enough and does its job, I guess I just don't understand what niche it fills that neither Ant nor Maven don't already handle?
We're (slowly) working on doing an upgrade to all our infrastructure, so one of the things we've examined is moving from Ant to Maven. While there's a lot of people that've expressed dissatisfaction with it, you can't ignore the fact that tutorials, setup instructions and such seemingly to a one are written with a pom.xml in mind.
So to that end, I wonder what place Gradle has. I've played with it a bit outside of this project and it seems nice enough and does its job, I guess I just don't understand what niche it fills that neither Ant nor Maven don't already handle?
One thing you will find in more complicated builds is that, short of writing your own Maven plugins, you will still need Ant scripts or at least some very arcane incantations of Maven to get the job done. I've used Maven for a long time and the vast majority of my projects are Maven based- for the ones that follow the archetype, Maven is a pretty easy fit. As a matter of fact if you've got an IDE like IntelliJ, it'll build your initial pom.xml for you and keep adding as you bring in libraries without having manually add them.
I have only recently begun using some Gradle builds after I hopped into an open source project that was using them and I'm quite impressed by the ease of it as well as the speed. You can have Gradle do a lot of the tasks you would've done with an Ant script + Maven pom. I'm already impressed with the lack of effort for sub-module builds, I've always found Maven to a pain for getting those working just right. Additionally, when you run the Gradle build daemon locally your builds are WAY faster than running Maven builds. I found the IntelliJ support for Gradle to be very good so far and I am going to continue to try converting a number of my existing projects over to Gradle as time allows.
EDIT: The main thing I really need to investigate with Gradle is what it does that is similar to a parent pom in Maven. We make pretty extensive use of parent poms in order to reduce boilerplate and keep dependency versions in sync, and we use Artifactory for everything.
EDIT2: This [0] Maven vs Gradle breakdown (though obviously pro-Gradle) highlights some areas where Gradle could really make a difference for people.
[0] https://gradle.org/maven_vs_gradle/
I have only recently begun using some Gradle builds after I hopped into an open source project that was using them and I'm quite impressed by the ease of it as well as the speed. You can have Gradle do a lot of the tasks you would've done with an Ant script + Maven pom. I'm already impressed with the lack of effort for sub-module builds, I've always found Maven to a pain for getting those working just right. Additionally, when you run the Gradle build daemon locally your builds are WAY faster than running Maven builds. I found the IntelliJ support for Gradle to be very good so far and I am going to continue to try converting a number of my existing projects over to Gradle as time allows.
EDIT: The main thing I really need to investigate with Gradle is what it does that is similar to a parent pom in Maven. We make pretty extensive use of parent poms in order to reduce boilerplate and keep dependency versions in sync, and we use Artifactory for everything.
EDIT2: This [0] Maven vs Gradle breakdown (though obviously pro-Gradle) highlights some areas where Gradle could really make a difference for people.
[0] https://gradle.org/maven_vs_gradle/
In Maven, the only way to share build logic is through a parent POM. Even if only four modules (out of 10) need to share some build logic, the only way is to get it into the parent POM.
So in most maven projects, the parent POM is a kitchen sink.
Gradle allows to create separate shared ".gradle" files that individual projects can import. This is push vs pull, and makes a world of a difference. So we have one shared "java_service.gradle" and one shared "java_library.gradle", and our submodules just do "apply from: <shared-build-file>".
Our root "build.gradle" is intentionally empty with a BIG warning never to add any shared logic in it.
This is just one of the reasons. You also see that with gradle, you can do "gradle test" on one submodule and it will compile all other dependencies but run tests only on this module. Maven, on the other hand, if you do "mvn test --pl <module> --also-make", will compile and test ALL related modules.
I can keep writing a long list of other stuff. But in the end, Maven is a "Project Management Tool" that tried to do a hundred things, and gets nothing right. Gradle is a proper good build tool.
So in most maven projects, the parent POM is a kitchen sink.
Gradle allows to create separate shared ".gradle" files that individual projects can import. This is push vs pull, and makes a world of a difference. So we have one shared "java_service.gradle" and one shared "java_library.gradle", and our submodules just do "apply from: <shared-build-file>".
Our root "build.gradle" is intentionally empty with a BIG warning never to add any shared logic in it.
This is just one of the reasons. You also see that with gradle, you can do "gradle test" on one submodule and it will compile all other dependencies but run tests only on this module. Maven, on the other hand, if you do "mvn test --pl <module> --also-make", will compile and test ALL related modules.
I can keep writing a long list of other stuff. But in the end, Maven is a "Project Management Tool" that tried to do a hundred things, and gets nothing right. Gradle is a proper good build tool.
This is not correct. One can import POM's in maven since maven 3.0.x (which is several years old). You are certainly not 'forced' to have build logic in only parent POM's.
Regarding parent poms, you can do something similar in gradle with the top-level build.gradle file.
Check out this project for an example of how that works: https://github.com/JakeWharton/butterknife
Check out this project for an example of how that works: https://github.com/JakeWharton/butterknife
We created a number of Gradle plugins for our common boilerplate. We publish those as a JAR into our internal Artifactory, and they're easily applied to any of our modules.
My view on the subject, FWIW: https://rule1.quora.com/Use-Maven-Not-Gradle
I must disagree with the notion that using Ant and Maven does not introduce a new language to the project. Using Ant does require you to learn a completely new language albeit one which follows the XML conventions. To say it is not new would be like comparing XHTML and XSLT, they are both XML and both are very different. I do not like the Gradle DSL because I find it chaotic and inconsistent, however sprinkling XML tags everywhere does not do much good for readability.
That's a fair point. Ant's XML usage is closer to a DSL than not. But, it's still much simpler than the various Gradle DSLs I've seen.
It seems to me that gradle has a performance edge (things like incremental rebuilds etc) although I haven't used it so I cannot say for sure.
My inner grumpy anti-hipster says it is mostly about riding the tail of the anti-xml wave though: "no xml? Then it must be good!"
My inner grumpy anti-hipster says it is mostly about riding the tail of the anti-xml wave though: "no xml? Then it must be good!"
From my Android SDK experience, Ant and Maven are much faster than Gradle.
If you check the developer Q&A videos at Google IO 2016, one of the issues that got discussed was precisely the slow builds.
It is also interesting that they had to re-write the public API in Java for Gradle 3, as part of their speed improvements.
If you check the developer Q&A videos at Google IO 2016, one of the issues that got discussed was precisely the slow builds.
It is also interesting that they had to re-write the public API in Java for Gradle 3, as part of their speed improvements.
From what I know, the Groovy runtime was a constant-time bottle neck for all builds (time to initialise, interpret etc.), hence the perceived "slow builds" for any small to medium sized project.
My experience is similar to yours - when not using the dragle daemon.
IIRC the gradle daemon made things competetive if not faster, though it's been a while since I tried.
IIRC the gradle daemon made things competetive if not faster, though it's been a while since I tried.
Yet Ant and Maven don't need a daemon to be fast.
There is a recent post from the Android team, where they advise to allocate between 2 and 5 GBs for the daemon!
There is a recent post from the Android team, where they advise to allocate between 2 and 5 GBs for the daemon!
(All of this is IME, of course:)
Maven is awful when you get to even moderately large projects -- there are many reasons (and I'm sure you can find them on the web). Yes, you can find heaps of documentation and StackOverflow answers which detail all the workarounds you'll need, but... wouldn't you rather have a system that didn't require huge amounts of documentation and workarounds in the first place?
(Btw, I'm not saying Gradle is the system which transports you to this holy land. I personally think it's hugely better than Maven in every conceivable way, though. Except if "better at being Maven" is a consideration, obviously.)
Maven is awful when you get to even moderately large projects -- there are many reasons (and I'm sure you can find them on the web). Yes, you can find heaps of documentation and StackOverflow answers which detail all the workarounds you'll need, but... wouldn't you rather have a system that didn't require huge amounts of documentation and workarounds in the first place?
(Btw, I'm not saying Gradle is the system which transports you to this holy land. I personally think it's hugely better than Maven in every conceivable way, though. Except if "better at being Maven" is a consideration, obviously.)
Gradle is the amazing middle ground between maven and ant.
Highly customizable like ant, but with a ton of predefined behaviors like maven. Unlike maven though, changing or customizing predefined behaviors is a lot easier.
Highly customizable like ant, but with a ton of predefined behaviors like maven. Unlike maven though, changing or customizing predefined behaviors is a lot easier.
Gradle + Kotlin should be renamed to Kradle, shouldn't it? =)
Massive fan of Gradle and Kotlin here. Can't wait to give this a whirl.
Massive fan of Gradle and Kotlin here. Can't wait to give this a whirl.
Has anybody tinkered with other build systems, like Buck, Basel or Pants? I've tinkered with Buck and I seems amazing for working with incremental recompilation for module based Java products - distributed caching based on caching of all inputs (including build files), true parallelism and ABI checks when deciding to recompile dependent code.
Don't get me wrong, the scope of Buck is much more limited than Gradle - where I work we have Gradle tasks for various things that don't quite fit into a build system, like deploying.
But boy, I'd love a plugin that uses Buck behind the scenes for compilation and artifact builds.
Aside: I brig this up because I've found it really hard to have a large Gradle project that is decoupled on the module level, preventing good parallelism.
Don't get me wrong, the scope of Buck is much more limited than Gradle - where I work we have Gradle tasks for various things that don't quite fit into a build system, like deploying.
But boy, I'd love a plugin that uses Buck behind the scenes for compilation and artifact builds.
Aside: I brig this up because I've found it really hard to have a large Gradle project that is decoupled on the module level, preventing good parallelism.
Problem with gradle is that every build script is its own special snowflake as Gradle does not impose build structure. I am glad that they are moving toward Kotlin as Groovy is awfully slow
Having worked on projects with fairly complex builds I have got the impression that most build systems are optimised for trivial scenarios and get very hacky when things get real. In the end we always end up with build.sh scripts that assemble several tools and perform tasks such as copying files etc. We often end up with CMake build that calls scripts and creates more build files to make the whole thing work. So, my question would be: why not have a build system for Java which is just a Java library and then the whole build process would be written in Java (or Scala)? Real™ languages are infinitely more expressive than build system DSLs and I find it that the default use case (just some dependencies, maybe build a doc) is actually quite rare. /rant
That's basically what Gradle is, with Groovy the current 'real' language (it's a dynamic scripting language) and Kotlin the next language (it's statically typed and like Scala).
Java is very verbose language and doesn't provide enough tools to write simple DSL. That's the main reason, IMO. People don't want their build scripts being very verbose. Though with Java 8 it might be better.
Please note that Maven written in Java and you can easily create your own plugin and use it from configuration. So you can do everything you want. The same applies for Gradle and probably every other Java build tool.
Also Gradle uses Groovy or Kotlin as a build script language. SBT uses Scala as a build script language. So it's similar to what you want.
Please note that Maven written in Java and you can easily create your own plugin and use it from configuration. So you can do everything you want. The same applies for Gradle and probably every other Java build tool.
Also Gradle uses Groovy or Kotlin as a build script language. SBT uses Scala as a build script language. So it's similar to what you want.
The problem is that it is not default or recommended way of doing things. My issue is that yes, people do want the build script language to be simple, but this (in my experience) always comes to bite you when the project gets bigger.
I mostly work with CMake and there we have to do a lot of arcane gymnastics to do basic stuff like list manipulation or moving files around, simply because the language has most of these features tacked on after the creator realises that they are necessary.
In Gradle, for example, I have a fairly trivial library that needs to build some native bindings at the right moment and after fighting with the DSL I ended up writing the build script in PowerShell and just call that. I think that the build systems I have encountered so far focus on the 'simple' case too much and render even little more advanced tasks tedious.
I would be happier with a build system that does not declare any magic variables or default steps.
I mostly work with CMake and there we have to do a lot of arcane gymnastics to do basic stuff like list manipulation or moving files around, simply because the language has most of these features tacked on after the creator realises that they are necessary.
In Gradle, for example, I have a fairly trivial library that needs to build some native bindings at the right moment and after fighting with the DSL I ended up writing the build script in PowerShell and just call that. I think that the build systems I have encountered so far focus on the 'simple' case too much and render even little more advanced tasks tedious.
I would be happier with a build system that does not declare any magic variables or default steps.
Because there are always some clever guys that make it so complex that everyone keeps debugging the build scripts when something goes wrong.
Specially bad on projects that are consultant driven, where customers hire consultants to work on specific features and then leave.
Specially bad on projects that are consultant driven, where customers hire consultants to work on specific features and then leave.
> Information about the Gradle Daemon is now being captured in your Build Scans and can be viewed in Gradle Cloud Services.
Does anyone know what that means...? It makes it sounds like it is auto uploading information about your build somewhere.
Does anyone know what that means...? It makes it sounds like it is auto uploading information about your build somewhere.
It seems you have to add the "build-scan" dependency to the build, agree to its license, then run your builds with an extra flag before it sends data off to their services.
At the moment there are two steps if you want to view a Build Scan, one is to add the plugin and the other is to add -DScan to the command line. Data doesn't go anywhere unless you have explicitly done both of those things. If you're curious how this works look here https://gradle.com/whats-new-gradle/
[deleted]
Anyone use a simple vendoring workflow in Java similar to golang ?
Yes, around 10 years ago, before Maven got invented to work around the issues caused by vendoring in Java, with Ant or Makefiles.
There's no point in using vendoring in a language with a dependency resolving build system.
What is a 'simple vendoring workflow'?
I contend that Groovy is the "bash" of the JVM: there may be use-cases for it, but it's so prone to becoming a minefield that you're often better off using a more fully-fledged language (one that's not so slow and doesn't aggressively hide errors from you in the name of being "dynamic")