7 ms·

Yo, new Gradle developer experience lead here. I fully empathize that it's much too difficult to wrap one's head around Gradle, so I want to share some things y

Yo, new Gradle developer experience lead here. I fully empathize that it's much too difficult to wrap one's head around Gradle, so I want to share some things you might find interesting: * The Gradle Kotlin DSL, which is nearing production-readiness, substantially improves the assistance/docs one gets through the IDE. * However, the Kotlin DSL does not help with the large API surface and understanding of Gradle concepts, so I have been working on improved docs and best practices for the past few months. * However, most folks don't or won't read docs, so additional tools will help users opt-in to strictness and quality checks that enforce best practices through the tool. Even with all that, one can think of build tools like languages: one tool will never be able to suit all needs or projects. However, I intend the broaden the audience for Gradle by making it more accessible to a wider audience. I'd love your help. My Twitter DMs are open @eriwen. DM me the 1 specific thing you would change about Gradle if you could. [EDIT]: Fixed the formatting of the bullet points.

bsder 8y ago
Fix the documentation! Focus on Android Studio because that's the only place people really use Gradle because they are forced to do so. You need to create a LOT of Android Studio sample projects, and they need to be kept up to date for the various versions of Android Studio. If you did nothing but create "Hello World" in a zillion various flavors (Java, Kotlin, Scala, NDK, NDK with static library on different architectures, etc.) for people, that would be huge. My specific beef is with NDK projects. Pulling in static libraries and compiling them with the NDK is a mix of magical keywords that sometimes materialize from some kind stranger via chat--generally because Gradle has to shove those keywords to something like CMake--which ALSO has an enormous learning curve.
- kodablah 8y ago
  > Focus on Android Studio because that's the only place people really use Gradle because they are forced to do so. False
  - pjmlp 8y ago
    It is true for us. If it wasn't forced upon us for Android dev no one at my employer would even bother to learn what is Gradle. The opinion is that it is the last spot keeping Groovy alive.
    - lomnakkus 8y ago
      Jenkins also semi-recently decided to go with Groovy for their "pipeline" feature. Ugh. (They may have good reasons, but anything that prolongs the lifespan of Groovy is a bad thing.)
- wendelinsky 8y ago
  Thanks for the feedback. Docs/samples oriented around Android could use some love for sure. I think one thing we need to figure out is how Google and Gradle can accomplish these things together.
  - bsder 8y ago
    > I think one thing we need to figure out is how Google and Gradle can accomplish these things together. We refer to that in the corporate world as "death by committee". You can solve the problem with a GitHub repository and an intern trawling StackOverflow and IRC logs. Choosing not do that sends a signal. Waiting for Google to "accomplish it together" (aka sometime before the heat death of the universe) is a good way to get replaced.
- dljsjr 8y ago
  Please don't say that nobody uses Gradle outside of Android devs. We're a shop that definitely does zero Android development and we still use Gradle, the fact that people assume Gradle <-> Anroid Dev is already a huge pain point for us when we start looking for third party educational resources.
  - pjmlp 8y ago
    At our shop we only care about Gradle, because Google forces ud to. Otherwise we would keep using only Maven for Java projects. Slower builds and higher hardware requirements for daemon and build cache are not worth it.
- lmilcin 8y ago
  While all Android Studio users are forced to use Gradle only handful will ever need anything more than the basic boilerplate generated by Studio. My Android projects are mostly private stuff but I don't remember any project that would require any kind of custom build. There is whole plethora of tools. My own calculators for various stuff, app to communicate with my family, apps to manage my electronics (bluetooth, wifi, cloud), apps to manage stuff in my Drive. My changes are mostly adding dependencies.
  - pjmlp 8y ago
    Try to integrate NDK builds or follow up on the continuous suggestions given at any major Android conference about how to speed up builds. That basic boilerplate is no longer enough and tricks change with each release.
- dcow 8y ago
  The gradle team doesn't work on android builds. They work closely with Xavier from googles android build tools team on that.
kodablah 8y ago
The key point that Gradle needs to make clearer is to delineate between task creation and task execution and which code is running where. It is very confusing for people to know whether their code is going to execute at gradle file load or at task execution. People get confused that they can't just use the result of one task when setting the opts for another. Edit: Also, I personally do the opposite route wrt the paradigm of the wrapper and the daemon. I don't commit a wrapper script and have people use a downloaded Gradle themselves. I also run --no-daemon on every manual execution for smaller projects. But I may not be normal here.
- dljsjr 8y ago
  Definitely agree with this. The Gradle lifecycle and the difference between Task Execution and Build Configuration is not intuitive at all. Neither is the fact that when you just stick a `<<` or `doLast()` in there without understanding why, it works with some tasks and not with others (killing << is a step in the right direction but making the build lifecycle more understandable would be hugely helpful).
  - twic 8y ago
    I used Gradle for a year or so before i grokked this distinction. Once i did, things became very simple indeed.
Boxxed 8y ago
Personally, I think Gradle (and a whole lot of other software) needs to stop the whole convention-over-configuration idea. It makes things way too difficult to debug and learn from, all to save some one-time typing. Making everything implicit for the sake of simplicity is really just the opposite.
- kodablah 8y ago
  > needs to stop the whole convention-over-configuration idea Yup, and while we're at it, realize that the declarative approach doesn't work after the first basic uses and even though your hello world build file is simple, most people need customization. Scripting the build system should be its main feature and everything else as just shortcuts (to be fair, Gradle kinda does this w/ tasks, but doesn't make it simple to just drop into code).
  - na85 8y ago
    This may be naive but doesn't GNU Make tick all these boxes in addition to being ubiquitous?
    - kodablah 8y ago
      Not ubiquitous and missing shortcuts. How do you compile 5 JVM projects in different JVM languages, sharing different configured sets of potentially hundreds of libraries across the classpath and make sure there are no versioning conflicts? Shortcuts are required, they just don't need to hide everything.
      - na85 8y ago
        I guess I'd compile them like anything else: using Make to invoke the compiler. Checking versions can be accomplished by using awk or another tool to compare output from $compiler --version. What am I missing?
        sk5t 8y ago
SureshG 8y ago
Using maven at work and Kotlin-DSL for my personal projects. One of the main pain points for using Kotlin DSL is the speed. It's order of magnitude slower than maven when used with IntelliJ IDE. Sometimes updating the `build.gradle.kts` file and reflecting the updates on IDE can take up to 5 mins. Apart from that really love the improvements made by Kotlin DSL. Finally, I can write the build script without going through the docs/stack overflow all the time.
solatic 8y ago
If you want ideas, you should check out Ratpack (a web framework for Groovy or Java) and the way the Ratpack.groovy DSL looks. * Convention over configuration: implicit defaults for everything so the hello world example is very simple. If you try to create a new Java project in Gradle, not by copying and pasting or having the IDE autogenerate something for you, you're going to have a bad time. * Whenever you do want to add something, there is a clear place within the structure of the root ratpack{} closure to add it. The port goes under serverConfig, routes go under handlers, etc. You don't set the port under the routing handlers, that would make no sense. Very different than build.gradle which feels like a flat list of unrelated tasks. * Support for both anonymous code and for code which has been factored out. Of course Gradle supports this (factoring out buildscript dependencies instead of a flat build.gradle) but the experience makes you feel like you're playing around with Frankenstein's monster so hardly anybody ever does so. * Documentation provides examples through tests, which clearly show both the code and the expected outcome, and which Ratpack prioritized being able to express in a concise manner precisely so that it could be used for documentation purposes. Could Ratpack have gotten rid of the root ratpack{} closure, the serverConfig and handlers and registry closures? Technically yes, they're not needed to namespace their children. But it would be so much less understandable.

bsder 8y ago

Fix the documentation! Focus on Android Studio because that's the only place people really use Gradle because they are forced to do so. You need to create a LOT of Android Studio sample projects, and they need to be kept up to date for the various versions of Android Studio. If you did nothing but create "Hello World" in a zillion various flavors (Java, Kotlin, Scala, NDK, NDK with static library on different architectures, etc.) for people, that would be huge. My specific beef is with NDK projects. Pulling in static libraries and compiling them with the NDK is a mix of magical keywords that sometimes materialize from some kind stranger via chat--generally because Gradle has to shove those keywords to something like CMake--which ALSO has an enormous learning curve.

kodablah 8y ago
> Focus on Android Studio because that's the only place people really use Gradle because they are forced to do so. False
- pjmlp 8y ago
  It is true for us. If it wasn't forced upon us for Android dev no one at my employer would even bother to learn what is Gradle. The opinion is that it is the last spot keeping Groovy alive.
  - lomnakkus 8y ago
    Jenkins also semi-recently decided to go with Groovy for their "pipeline" feature. Ugh. (They may have good reasons, but anything that prolongs the lifespan of Groovy is a bad thing.)
wendelinsky 8y ago
Thanks for the feedback. Docs/samples oriented around Android could use some love for sure. I think one thing we need to figure out is how Google and Gradle can accomplish these things together.
- bsder 8y ago
  > I think one thing we need to figure out is how Google and Gradle can accomplish these things together. We refer to that in the corporate world as "death by committee". You can solve the problem with a GitHub repository and an intern trawling StackOverflow and IRC logs. Choosing not do that sends a signal. Waiting for Google to "accomplish it together" (aka sometime before the heat death of the universe) is a good way to get replaced.
dljsjr 8y ago
Please don't say that nobody uses Gradle outside of Android devs. We're a shop that definitely does zero Android development and we still use Gradle, the fact that people assume Gradle <-> Anroid Dev is already a huge pain point for us when we start looking for third party educational resources.
- pjmlp 8y ago
  At our shop we only care about Gradle, because Google forces ud to. Otherwise we would keep using only Maven for Java projects. Slower builds and higher hardware requirements for daemon and build cache are not worth it.
lmilcin 8y ago
While all Android Studio users are forced to use Gradle only handful will ever need anything more than the basic boilerplate generated by Studio. My Android projects are mostly private stuff but I don't remember any project that would require any kind of custom build. There is whole plethora of tools. My own calculators for various stuff, app to communicate with my family, apps to manage my electronics (bluetooth, wifi, cloud), apps to manage stuff in my Drive. My changes are mostly adding dependencies.
- pjmlp 8y ago
  Try to integrate NDK builds or follow up on the continuous suggestions given at any major Android conference about how to speed up builds. That basic boilerplate is no longer enough and tricks change with each release.
dcow 8y ago
The gradle team doesn't work on android builds. They work closely with Xavier from googles android build tools team on that.

kodablah 8y ago

The key point that Gradle needs to make clearer is to delineate between task creation and task execution and which code is running where. It is very confusing for people to know whether their code is going to execute at gradle file load or at task execution. People get confused that they can't just use the result of one task when setting the opts for another. Edit: Also, I personally do the opposite route wrt the paradigm of the wrapper and the daemon. I don't commit a wrapper script and have people use a downloaded Gradle themselves. I also run --no-daemon on every manual execution for smaller projects. But I may not be normal here.

dljsjr 8y ago
Definitely agree with this. The Gradle lifecycle and the difference between Task Execution and Build Configuration is not intuitive at all. Neither is the fact that when you just stick a `<<` or `doLast()` in there without understanding why, it works with some tasks and not with others (killing << is a step in the right direction but making the build lifecycle more understandable would be hugely helpful).
- twic 8y ago
  I used Gradle for a year or so before i grokked this distinction. Once i did, things became very simple indeed.

Boxxed 8y ago

Personally, I think Gradle (and a whole lot of other software) needs to stop the whole convention-over-configuration idea. It makes things way too difficult to debug and learn from, all to save some one-time typing. Making everything implicit for the sake of simplicity is really just the opposite.

kodablah 8y ago
> needs to stop the whole convention-over-configuration idea Yup, and while we're at it, realize that the declarative approach doesn't work after the first basic uses and even though your hello world build file is simple, most people need customization. Scripting the build system should be its main feature and everything else as just shortcuts (to be fair, Gradle kinda does this w/ tasks, but doesn't make it simple to just drop into code).
- na85 8y ago
  This may be naive but doesn't GNU Make tick all these boxes in addition to being ubiquitous?
  - kodablah 8y ago
    Not ubiquitous and missing shortcuts. How do you compile 5 JVM projects in different JVM languages, sharing different configured sets of potentially hundreds of libraries across the classpath and make sure there are no versioning conflicts? Shortcuts are required, they just don't need to hide everything.
    - na85 8y ago
      I guess I'd compile them like anything else: using Make to invoke the compiler. Checking versions can be accomplished by using awk or another tool to compare output from $compiler --version. What am I missing?
      - sk5t 8y ago

SureshG 8y ago

Using maven at work and Kotlin-DSL for my personal projects. One of the main pain points for using Kotlin DSL is the speed. It's order of magnitude slower than maven when used with IntelliJ IDE. Sometimes updating the `build.gradle.kts` file and reflecting the updates on IDE can take up to 5 mins. Apart from that really love the improvements made by Kotlin DSL. Finally, I can write the build script without going through the docs/stack overflow all the time.

solatic 8y ago

If you want ideas, you should check out Ratpack (a web framework for Groovy or Java) and the way the Ratpack.groovy DSL looks. * Convention over configuration: implicit defaults for everything so the hello world example is very simple. If you try to create a new Java project in Gradle, not by copying and pasting or having the IDE autogenerate something for you, you're going to have a bad time. * Whenever you do want to add something, there is a clear place within the structure of the root ratpack{} closure to add it. The port goes under serverConfig, routes go under handlers, etc. You don't set the port under the routing handlers, that would make no sense. Very different than build.gradle which feels like a flat list of unrelated tasks. * Support for both anonymous code and for code which has been factored out. Of course Gradle supports this (factoring out buildscript dependencies instead of a flat build.gradle) but the experience makes you feel like you're playing around with Frankenstein's monster so hardly anybody ever does so. * Documentation provides examples through tests, which clearly show both the code and the expected outcome, and which Ratpack prioritized being able to express in a concise manner precisely so that it could be used for documentation purposes. Could Ratpack have gotten rid of the root ratpack{} closure, the serverConfig and handlers and registry closures? Technically yes, they're not needed to namespace their children. But it would be so much less understandable.