43 ms·

Sometimes I feel they should stop the development of all new features and concentrate exclusively on performance improvement (which, fortunately, is not neglect

Sometimes I feel they should stop the development of all new features and concentrate exclusively on performance improvement (which, fortunately, is not neglected in this release).

okr 6y ago
Yup. I also stopped upgrading. Too much work.
- josteink 6y ago
  Granted it was many years ago, but my only experience with Gradle was through Android Studio. Basically, as I remember it, every time Android studio updated Gradle, my project broke. No exceptions, even though this was a stock Android Studio project. Seemingly things are still that terrible? If so, why do you people keep using it? What problems does Gradle solve which other build-systems don’t solve better
  - ohgodplsno 6y ago
    Gradle is sufficiently implanted into the Android ecosytem that moving away is hard. When you have a project with 80+ modules, buildSrc contents, gradle plugins, well, moving to Bazel isn't exactly a one day job. Add to that that many things add Gradle plugins that might be necessary for your workflow, and well, you're in a bad state.
    - thu2111 6y ago
      Unfortunately that's also now the case for the Kotlin ecosystem. I attempted to use Maven recently for a simple Kotlin project and recently switched to Gradle. This is NOT because I like Gradle. Oh god if there is any project and company that badly needs some competition it is Gradle Inc. But the Maven/Kotlin ecosystem is bit-rotting. Maven itself is hardly maintained. It's now common to find libraries or tools that only really work properly with Gradle and de-prioritise Maven related issues. Gradle is winning by default, even though it's arguably a step sideways from Maven.
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.
vbezhenar 6y ago
What features do you think they should not ship? Apple Silicon support obviously is necessary. Support for Java 16 is necessary. Centralized dependency management is long-awaited feature. Type safe project accessors are very nice to have. I would say that they should not stop the development of all new features, but rather they should spend more time designing those features, so they don't have to change them in the future (making old variants obsolete and broken in the end). But modern software development is agile, move fast and break things and all that.
popotamonga 6y ago
I never understood why my android app with only 300 classes and 20 libs takes more than 1m to build on my custom 5k$ computer. In comparison i have a c# project 3x bigger and only takes a few seconds to fully rebuild. Maybe its just how android is and nothing to do with graddle but still...
- ohgodplsno 6y ago
  A lot of it is Android, yes. A regular build run will involve kotlin annotation processing, kotlin compilation, java annotation processing, java compilation, AAPT2, dexing, sometimes d8/r8 if you're in release mode, as well as a whole host of various processes that you can forget about until it hits you with a build error that will have you puzzled for a few hours. EDIT: right, Jetifier too, because that's always a lot of fun.
- kaba0 6y ago
  From experience, non-android java project will build roughly in the same time as comparable amount of C# code, with both maven and gradle. It is definitely android that increases it.

Sometimes I feel they should stop the development of all new features and concentrate exclusively on performance improvement (which, fortunately, is not neglected in this release).

okr 6y ago

Yup. I also stopped upgrading. Too much work.

josteink 6y ago
Granted it was many years ago, but my only experience with Gradle was through Android Studio. Basically, as I remember it, every time Android studio updated Gradle, my project broke. No exceptions, even though this was a stock Android Studio project. Seemingly things are still that terrible? If so, why do you people keep using it? What problems does Gradle solve which other build-systems don’t solve better
- ohgodplsno 6y ago
  Gradle is sufficiently implanted into the Android ecosytem that moving away is hard. When you have a project with 80+ modules, buildSrc contents, gradle plugins, well, moving to Bazel isn't exactly a one day job. Add to that that many things add Gradle plugins that might be necessary for your workflow, and well, you're in a bad state.
  - thu2111 6y ago
    Unfortunately that's also now the case for the Kotlin ecosystem. I attempted to use Maven recently for a simple Kotlin project and recently switched to Gradle. This is NOT because I like Gradle. Oh god if there is any project and company that badly needs some competition it is Gradle Inc. But the Maven/Kotlin ecosystem is bit-rotting. Maven itself is hardly maintained. It's now common to find libraries or tools that only really work properly with Gradle and de-prioritise Maven related issues. Gradle is winning by default, even though it's arguably a step sideways from Maven.

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.

vbezhenar 6y ago

What features do you think they should not ship? Apple Silicon support obviously is necessary. Support for Java 16 is necessary. Centralized dependency management is long-awaited feature. Type safe project accessors are very nice to have. I would say that they should not stop the development of all new features, but rather they should spend more time designing those features, so they don't have to change them in the future (making old variants obsolete and broken in the end). But modern software development is agile, move fast and break things and all that.

popotamonga 6y ago

I never understood why my android app with only 300 classes and 20 libs takes more than 1m to build on my custom 5k$ computer. In comparison i have a c# project 3x bigger and only takes a few seconds to fully rebuild. Maybe its just how android is and nothing to do with graddle but still...

ohgodplsno 6y ago
A lot of it is Android, yes. A regular build run will involve kotlin annotation processing, kotlin compilation, java annotation processing, java compilation, AAPT2, dexing, sometimes d8/r8 if you're in release mode, as well as a whole host of various processes that you can forget about until it hits you with a build error that will have you puzzled for a few hours. EDIT: right, Jetifier too, because that's always a lot of fun.
kaba0 6y ago
From experience, non-android java project will build roughly in the same time as comparable amount of C# code, with both maven and gradle. It is definitely android that increases it.