3 ms·

Even before that I'd prefer them improving the documentation :) . It's pretty senseless to have a system with even a good performance which can't be used becaus

by avmich 6y ago

Even before that I'd prefer them improving the documentation :) . It's pretty senseless to have a system with even a good performance which can't be used because of a cryptic behavior. I'm yet to see a good explanation for how Gradle should be used. Is knowing Groovy a prerequisite?

scaladev 6y ago
These days you can write build scripts in Kotlin. It provides proper type checking and better auto-completion.
vbezhenar 6y ago
I don't know which documentation do you miss. Gradle has pretty extensive documentation, stackoverflow has all kinds of answers and other websites have plenty of tutorials. I don't know Groovy and I was able to write complicated enough multi-project builds with some custom build steps by copy-pasting snippets from the Internet and applying some common sense. I guess, Groovy knowledge is required if you need to write build plugins.
- vesinisa 6y ago
  No, Gradle's documentation is really terrible. There is just no easy path to learn it - you will with time and pain learn a bit of the interface, but deep down it remains mostly unfanthonable, unnecessarily complex and filled with strange quirks. Bruce Eckel had pretty much the same experience as myself: https://www.bruceeckel.com/2021/01/02/the-problem-with-gradle/ https://www.bruceeckel.com/2021/01/02/the-problem-with-gradl... Everone "learns" Gradle by copy-pasting snippets from the Internet and then having to fix them when they break. And what little I have learned of Gradle over the years was certainly not thanks to their documentation, but other people explaining the concepts in blog posts and tutorials. The Gradle documentation always assumes that you will want to learn the whole build system from ground up. There is no simple documentation for people who see Gradle just as a tool secondary to their actual product that is just built with it. It is in many ways similar to git. You can't really learn git unless you learn it from the ground up. But git is actually really simple when compared to Gradle, and most people do learn git eventually through using it. But I am yet to encounter a developer who actually learned Gradle inside out just from using it and reading the documentation. Oh, and at least git's interface and structure has remained mostly static ever since the original concept by Linus in 2005. Same can not be said of Gradle - I feel like the developer interface is like a sand castle that is washed away every second release, and I assume the internals keep shifting as well. What a nightmare to work with.
  - njitbew 6y ago
    This is funny, because I have the complete opposite experience. Yes, it took me an afternoon to find my way around Gradle. But ever since I really appreciate their documentation. It is to the point, well written, contains code samples (which I believe are unit-tested, so they the code samples are always up-to-date), contains examples in both Groovy & Kotlin, and I could keep going on. A good entry point, for example, is Build Script Basics (https://docs.gradle.org/current/userguide/tutorial_using_tasks.html https://docs.gradle.org/current/userguide/tutorial_using_tas...). > But I am yet to encounter a developer who actually learned Gradle inside out just from using it and reading the documentation. You just met him! ;)
    - Hackbraten 6y ago
      One thing that keeps disappointing me is the utter lack of reference-style (API) documentation. Sure, the conceptual documents contain examples. But if the example isn’t clear enough, you’re completely on your own. For example, the following document has been largely useless to me even though I’ve spent whole days trying to make the examples work for me: https://docs.gradle.org/current/userguide/cross_project_publications.html https://docs.gradle.org/current/userguide/cross_project_publ...
      - fcurts 6y ago
        Gradle has had reference-style API documentation for as long as I can think: https://docs.gradle.org/current/dsl/index.html https://docs.gradle.org/current/dsl/index.html
    - vesinisa 6y ago
      You are probably doing a bit simpler stuff, if that basic tutorial suffices you. I should have maybe added that I do Android development with Gradle. There you don't as much start with an empty build file to write the tasks to compile your project, but instead have to navigate a pre-existing large build file and figure how to correctly use the Google and Gradle interfaces to integrate to the Android build tools, such as the dreaded AGP (Android Gradle Plugin). Which by the way is actually mostly undocumnented AFAIK!
- lmm 6y ago
  The documentation I'm missing is: what tasks, sourcesets, etc. exist by default? Where are they defined? I don't want to do some kind of runtime introspection in a build environment shell to find out what the project build does, I want a static list of all the tasks and which depends on what.
jlund-molfese 6y ago
These days the Kotlin DSL is treated as a first class citizen and you can find examples for most common tasks in either language. But Groovy is pretty easy to pick up too, you definitely don't need to know it before you start using it with Gradle. Aside from the performance implications, Gradle excels when used with more complex builds with many steps. If Maven works for your use case, your build scripts aren't unmanageably long, and your team doesn't mind XML, there isn't much of a reason to switch.

by avmich 6y ago

scaladev 6y ago

These days you can write build scripts in Kotlin. It provides proper type checking and better auto-completion.

vbezhenar 6y ago

I don't know which documentation do you miss. Gradle has pretty extensive documentation, stackoverflow has all kinds of answers and other websites have plenty of tutorials. I don't know Groovy and I was able to write complicated enough multi-project builds with some custom build steps by copy-pasting snippets from the Internet and applying some common sense. I guess, Groovy knowledge is required if you need to write build plugins.

vesinisa 6y ago
No, Gradle's documentation is really terrible. There is just no easy path to learn it - you will with time and pain learn a bit of the interface, but deep down it remains mostly unfanthonable, unnecessarily complex and filled with strange quirks. Bruce Eckel had pretty much the same experience as myself: https://www.bruceeckel.com/2021/01/02/the-problem-with-gradle/ https://www.bruceeckel.com/2021/01/02/the-problem-with-gradl... Everone "learns" Gradle by copy-pasting snippets from the Internet and then having to fix them when they break. And what little I have learned of Gradle over the years was certainly not thanks to their documentation, but other people explaining the concepts in blog posts and tutorials. The Gradle documentation always assumes that you will want to learn the whole build system from ground up. There is no simple documentation for people who see Gradle just as a tool secondary to their actual product that is just built with it. It is in many ways similar to git. You can't really learn git unless you learn it from the ground up. But git is actually really simple when compared to Gradle, and most people do learn git eventually through using it. But I am yet to encounter a developer who actually learned Gradle inside out just from using it and reading the documentation. Oh, and at least git's interface and structure has remained mostly static ever since the original concept by Linus in 2005. Same can not be said of Gradle - I feel like the developer interface is like a sand castle that is washed away every second release, and I assume the internals keep shifting as well. What a nightmare to work with.
- njitbew 6y ago
  This is funny, because I have the complete opposite experience. Yes, it took me an afternoon to find my way around Gradle. But ever since I really appreciate their documentation. It is to the point, well written, contains code samples (which I believe are unit-tested, so they the code samples are always up-to-date), contains examples in both Groovy & Kotlin, and I could keep going on. A good entry point, for example, is Build Script Basics (https://docs.gradle.org/current/userguide/tutorial_using_tasks.html https://docs.gradle.org/current/userguide/tutorial_using_tas...). > But I am yet to encounter a developer who actually learned Gradle inside out just from using it and reading the documentation. You just met him! ;)
  - Hackbraten 6y ago
    One thing that keeps disappointing me is the utter lack of reference-style (API) documentation. Sure, the conceptual documents contain examples. But if the example isn’t clear enough, you’re completely on your own. For example, the following document has been largely useless to me even though I’ve spent whole days trying to make the examples work for me: https://docs.gradle.org/current/userguide/cross_project_publications.html https://docs.gradle.org/current/userguide/cross_project_publ...
    - fcurts 6y ago
      Gradle has had reference-style API documentation for as long as I can think: https://docs.gradle.org/current/dsl/index.html https://docs.gradle.org/current/dsl/index.html
  - vesinisa 6y ago
    You are probably doing a bit simpler stuff, if that basic tutorial suffices you. I should have maybe added that I do Android development with Gradle. There you don't as much start with an empty build file to write the tasks to compile your project, but instead have to navigate a pre-existing large build file and figure how to correctly use the Google and Gradle interfaces to integrate to the Android build tools, such as the dreaded AGP (Android Gradle Plugin). Which by the way is actually mostly undocumnented AFAIK!
lmm 6y ago
The documentation I'm missing is: what tasks, sourcesets, etc. exist by default? Where are they defined? I don't want to do some kind of runtime introspection in a build environment shell to find out what the project build does, I want a static list of all the tasks and which depends on what.

jlund-molfese 6y ago

These days the Kotlin DSL is treated as a first class citizen and you can find examples for most common tasks in either language. But Groovy is pretty easy to pick up too, you definitely don't need to know it before you start using it with Gradle. Aside from the performance implications, Gradle excels when used with more complex builds with many steps. If Maven works for your use case, your build scripts aren't unmanageably long, and your team doesn't mind XML, there isn't much of a reason to switch.