
Gradle 3.0 Release Notes - vbezhenar
https://docs.gradle.org/current/release-notes
======
ubertaco
It is telling that the most high-profile, most-widely-used Groovy project has
chosen to rewrite their own code into Java for performance reasons, and is
touting the ability for end-users to write build scripts in Kotlin instead of
Gradle to get better tooling and performance.

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")

~~~
mikojava
I think you mean "Kotlin instead of Groovy"

~~~
vorg
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.

------
benjaminpv
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?

~~~
manyxcxi
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/](https://gradle.org/maven_vs_gradle/)

~~~
rdsubhas
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.

~~~
lenkite
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.

------
darylteo
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.

------
swsieber
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.

------
scaleout1
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

------
yoz-y
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

~~~
vbezhenar
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.

~~~
yoz-y
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.

------
dlandis
> 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.

~~~
WatchDog
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.

~~~
mikojava
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/](https://gradle.com/whats-new-gradle/)

------
naveen99
Anyone use a simple vendoring workflow in Java similar to golang ?

~~~
pjmlp
Yes, around 10 years ago, before Maven got invented to work around the issues
caused by vendoring in Java, with Ant or Makefiles.

