10 ms·

> This is the problem I had with Gradle: > To do anything you have to know everything This sums it up pretty well. Coming from a background of using Maven pu

by koolba 6y ago

> This is the problem I had with Gradle: > To do anything you have to know everything This sums it up pretty well. Coming from a background of using Maven purely for dependency management and basic compilation, existing Gradle projects are incredibly unapproachable and slow. And don’t get me started on the background daemons to speed things up either.

rwbhn 6y ago
Came here to post the same quote. Matches my experience as well.
- smitty1e 6y ago
  Then there is Jenkins. I looked at the jenkinsfile and said "I guess Java and Python had a tryst?" Eventually we'll get to the GitLab CI/CD, but the existing disaster supports the status quo, so it's not a priority.
  - noisy_boy 6y ago
    My experience with JenkinsFile has improved once we setup library functions for it to leverage on. Only downside is that you need to write them in Groovy but the payoff is that the JenkinsFile reduces to basically a function call or two per stage which makes it super clean + it makes JenkinsFiles more or less "standard" (because there is practically no project-specific stuff in it - the complexity is managed by the library functions). This approach has made fixing issues or enhancements so much more easier for us.
    - smitty1e 6y ago
      The "goodness" of Jenkins for my use-case is that the service can be a kind of "sudo" for capabilities we don't want to spread around. That said, learning Yet Another Language that only deals with a niche requirement is a total bore. If we can cook it down to executing some garden-variety bash in a special context, along with some spiffy pipeline visualization, that is enough.
      - noisy_boy 6y ago
        At the end of the day, its just the shell executing the commands :) sure, you can always distil it down to a script (or a set of scripts) and nothing wrong with it either - as always, depends on the context.
mrec 6y ago
Yup. Gradle is by far the worst-designed technology I've encountered in ~30 years of programming. Using it not only made me not want to use Gradle, it made me not want to use Java.
- TheRealSteel 6y ago
  I don't understand why Gradle breaks every second time I build my project, and I have to run Clean Project. If Clean Project is required to build the project, why isn't that part of the build process?
  - rwoerz 6y ago
    Same for Maven. Common reason: the mere presence of a "leftover after refactoring" file beneath target/ breaks the build because it is still included in the classpath.
    - eitland 6y ago
      FWIW: I've used Maven for years and I don't have these problems. When I am tasked with fixong other peoples config I usually move things to the correct location, delete the corresponding configuration qnd then everything works (better).
- allenbrunson 6y ago
  hard agree. i took up flutter a couple of years ago, which means i am now saddled with (ugh) gradle for android builds. i am used to being able to intuit the underlying architecture of various tech things and fix them, which is utterly impossible as far as gradle goes. not only are the error messages unhelpful, they are usually confidently incorrect. they tell you the problem is likely thing X, which in fact has nothing to do with the problem. (to be fair, this seems to be coming from whatever stuff google has added to the android build process, rather than gradle itself.) these days, once gradle starts spitting errors, i know better than to read them. instead, i have to start thinking about when the build last worked, and what might have changed. if that path proves not to bear fruit, then it is time to trash that project completely and recreate it from scratch, which experience has taught me will take a lot less time than trying to “fix” the gradle build errors.
bitcharmer 6y ago
I have the same impression of gradle. If I have to learn another language (groovy) and a whole new platform infrastructure and APIs just to understand what a build does, it's definitely not worth the effort. Most of my peers have the same views. Fun fact: look up gradle in urban dictionary.
- zmmmmm 6y ago
  This argument I don't really get. You're going to learn a "language" anyway - whatever build system you employ. It may or may not be Turing complete, but you're going to end up learning it once you get to any level of complexity in what you are doing. Why not have it be something with more general usefulness as well?
  - santoshalper 6y ago
    I have something with more general usefulness. It's called Java. I don't need a programming language to build my programming language.
posedge 6y ago
Yeah about that, do you have some insight on why the X background daemons are always 'incompatible' and gradle launches up new ones?
- gddhn 6y ago
  Being new to Gradle, I used to run into this same issue. In one of the projects I use, I happened to find this comment, in github, which helped me fix the issue https://github.com/quarkusio/quarkus/issues/10454#issuecomment-653731422 https://github.com/quarkusio/quarkus/issues/10454#issuecomme... So increasing the default max heap size of the gradle build helped fix the issue https://github.com/quarkusio/quarkus/pull/10508/files https://github.com/quarkusio/quarkus/pull/10508/files.
  - benibela 6y ago
    And how could I make sure that the gradle I start on the command line and the gradle started by Android Studio use the same daemon?

by koolba 6y ago

rwbhn 6y ago

Came here to post the same quote. Matches my experience as well.

smitty1e 6y ago
Then there is Jenkins. I looked at the jenkinsfile and said "I guess Java and Python had a tryst?" Eventually we'll get to the GitLab CI/CD, but the existing disaster supports the status quo, so it's not a priority.
- noisy_boy 6y ago
  My experience with JenkinsFile has improved once we setup library functions for it to leverage on. Only downside is that you need to write them in Groovy but the payoff is that the JenkinsFile reduces to basically a function call or two per stage which makes it super clean + it makes JenkinsFiles more or less "standard" (because there is practically no project-specific stuff in it - the complexity is managed by the library functions). This approach has made fixing issues or enhancements so much more easier for us.
  - smitty1e 6y ago
    The "goodness" of Jenkins for my use-case is that the service can be a kind of "sudo" for capabilities we don't want to spread around. That said, learning Yet Another Language that only deals with a niche requirement is a total bore. If we can cook it down to executing some garden-variety bash in a special context, along with some spiffy pipeline visualization, that is enough.
    - noisy_boy 6y ago
      At the end of the day, its just the shell executing the commands :) sure, you can always distil it down to a script (or a set of scripts) and nothing wrong with it either - as always, depends on the context.

mrec 6y ago

Yup. Gradle is by far the worst-designed technology I've encountered in ~30 years of programming. Using it not only made me not want to use Gradle, it made me not want to use Java.

TheRealSteel 6y ago
I don't understand why Gradle breaks every second time I build my project, and I have to run Clean Project. If Clean Project is required to build the project, why isn't that part of the build process?
- rwoerz 6y ago
  Same for Maven. Common reason: the mere presence of a "leftover after refactoring" file beneath target/ breaks the build because it is still included in the classpath.
  - eitland 6y ago
    FWIW: I've used Maven for years and I don't have these problems. When I am tasked with fixong other peoples config I usually move things to the correct location, delete the corresponding configuration qnd then everything works (better).
allenbrunson 6y ago
hard agree. i took up flutter a couple of years ago, which means i am now saddled with (ugh) gradle for android builds. i am used to being able to intuit the underlying architecture of various tech things and fix them, which is utterly impossible as far as gradle goes. not only are the error messages unhelpful, they are usually confidently incorrect. they tell you the problem is likely thing X, which in fact has nothing to do with the problem. (to be fair, this seems to be coming from whatever stuff google has added to the android build process, rather than gradle itself.) these days, once gradle starts spitting errors, i know better than to read them. instead, i have to start thinking about when the build last worked, and what might have changed. if that path proves not to bear fruit, then it is time to trash that project completely and recreate it from scratch, which experience has taught me will take a lot less time than trying to “fix” the gradle build errors.

bitcharmer 6y ago

I have the same impression of gradle. If I have to learn another language (groovy) and a whole new platform infrastructure and APIs just to understand what a build does, it's definitely not worth the effort. Most of my peers have the same views. Fun fact: look up gradle in urban dictionary.

zmmmmm 6y ago
This argument I don't really get. You're going to learn a "language" anyway - whatever build system you employ. It may or may not be Turing complete, but you're going to end up learning it once you get to any level of complexity in what you are doing. Why not have it be something with more general usefulness as well?
- santoshalper 6y ago
  I have something with more general usefulness. It's called Java. I don't need a programming language to build my programming language.

posedge 6y ago

Yeah about that, do you have some insight on why the X background daemons are always 'incompatible' and gradle launches up new ones?

gddhn 6y ago
Being new to Gradle, I used to run into this same issue. In one of the projects I use, I happened to find this comment, in github, which helped me fix the issue https://github.com/quarkusio/quarkus/issues/10454#issuecomment-653731422 https://github.com/quarkusio/quarkus/issues/10454#issuecomme... So increasing the default max heap size of the gradle build helped fix the issue https://github.com/quarkusio/quarkus/pull/10508/files https://github.com/quarkusio/quarkus/pull/10508/files.
- benibela 6y ago
  And how could I make sure that the gradle I start on the command line and the gradle started by Android Studio use the same daemon?