7 ms·

My problem with gradle is that its configuration language is a programming language. Sounds amazing in practice. And it is. Until you need to fix a 3 year old

My problem with gradle is that its configuration language is a programming language. Sounds amazing in practice. And it is. Until you need to fix a 3 year old build that has some insane wizardry going on.

mdaniel 2y ago
> Until you need to fix a 3 year old build that has some insane wizardry going on. My experience with Gradle is that it's the "3 year old build" that is almost certainly a death knell more than the insane wizardry part. My experience: git clone .../ancient-codebase.git cd ancient-codebase ./gradlew # <-- oh, the wrapper, so it will download the version it wants, hazzah! for _ in $(seq 1 infinity); do echo gradle vomit you have to sift through; done echo 'BUILD FAILED' >&2 exit 1 Contrast that with https://github.com/apache/maven-app-engine https://github.com/apache/maven-app-engine (just to pick on something sorted by earliest push date, some 10 years ago): $ git clone https://github.com/apache/maven-app-engine.git $ cd maven-app-engine $ mvn -B compile [INFO] ------------------------------------------------------------- [ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] error: Source option 6 is no longer supported. Use 8 or later. [ERROR] error: Target option 6 is no longer supported. Use 8 or later. [INFO] 2 errors $ echo "Java gonna Java" $ git grep -n source.*6 pom.xml:133: <source>1.6</source> $ sed -i.bak -e 's/1.6/1.8/g' pom.xml $ mvn -B compile [INFO] BUILD SUCCESS
- brabel 2y ago
  I dislike Gradle as much as you probably do, but between Maven and Gradle, the one that "vomits" stuff on the command line is definitely Maven. Gradle errs by going too far to the other end: it just doesn't log anything at all, even the tasks that are actually being run (vs skipped... do you know how to get Gradle to show them?? It's `gradle --console=plain`, so obvious!! Why would anyone complain about that, right?!) or the print outs you add to the build to try to understand what the heck is going on.
dkarl 2y ago
Having worked with Maven and Gradle, I'd say Gradle was worse in the average case, but better in the worst case. There are way more Gradle projects with unnecessary custom build code because Gradle makes it easy to do. On the other hand, when builds are specified in a limited-power build config language, like POM, then when someone needs to do something custom, they have to extend or modify the build tool itself, which in my experience causes way more pain than custom code in a build file. Custom logic in Maven means building and publishing an extension; it can't be local to the project. You may encounter projects that depend on extensions from long-lost open source projects, or long-lost internal projects. On one occasion, I was lucky to find a source jar for the extension in the Maven repository. It can be a nightmare. The same could happen with Gradle, since a build can depend on arbitrary libraries, but I never saw it in the wild. People depended on major open-source extensions and added their own custom code inside the build.
- cyberax 2y ago
  > it can't be local to the project It certainly can be, in the same repository.
  - dkarl 2y ago
    When I used Maven, extensions had to be published to and pulled from a public repo. We couldn't even use the private repo that we used for the rest of our libraries, because the extension had to be loaded before Maven read the file where our private repo was configured. Whereas a Gradle build can read Groovy files straight from disk.
    - cyberax 2y ago
      > When I used Maven, extensions had to be published to and pulled from a public repo. You can just `mvn install` them locally into your local repository.
      - lihaoyi 2y ago
        You can, but why should you need to? Why can't the build tool take the plugin code directly off of disk, build it, and use it? This kind of orchestration of manual steps is what build tools are meant to be good at
chikere232 2y ago
My problem with gradle is that they keep making breaking changes for low value things like naming of options, so I have to chase deprecation warnings, and can never rely on a distro supplied gradle version Gradle devs, please get over yourself and stay backward compatible.

mdaniel 2y ago

> Until you need to fix a 3 year old build that has some insane wizardry going on. My experience with Gradle is that it's the "3 year old build" that is almost certainly a death knell more than the insane wizardry part. My experience: git clone .../ancient-codebase.git cd ancient-codebase ./gradlew # <-- oh, the wrapper, so it will download the version it wants, hazzah! for _ in $(seq 1 infinity); do echo gradle vomit you have to sift through; done echo 'BUILD FAILED' >&2 exit 1 Contrast that with https://github.com/apache/maven-app-engine https://github.com/apache/maven-app-engine (just to pick on something sorted by earliest push date, some 10 years ago): $ git clone https://github.com/apache/maven-app-engine.git $ cd maven-app-engine $ mvn -B compile [INFO] ------------------------------------------------------------- [ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] error: Source option 6 is no longer supported. Use 8 or later. [ERROR] error: Target option 6 is no longer supported. Use 8 or later. [INFO] 2 errors $ echo "Java gonna Java" $ git grep -n source.*6 pom.xml:133: <source>1.6</source> $ sed -i.bak -e 's/1.6/1.8/g' pom.xml $ mvn -B compile [INFO] BUILD SUCCESS

brabel 2y ago
I dislike Gradle as much as you probably do, but between Maven and Gradle, the one that "vomits" stuff on the command line is definitely Maven. Gradle errs by going too far to the other end: it just doesn't log anything at all, even the tasks that are actually being run (vs skipped... do you know how to get Gradle to show them?? It's `gradle --console=plain`, so obvious!! Why would anyone complain about that, right?!) or the print outs you add to the build to try to understand what the heck is going on.

dkarl 2y ago

Having worked with Maven and Gradle, I'd say Gradle was worse in the average case, but better in the worst case. There are way more Gradle projects with unnecessary custom build code because Gradle makes it easy to do. On the other hand, when builds are specified in a limited-power build config language, like POM, then when someone needs to do something custom, they have to extend or modify the build tool itself, which in my experience causes way more pain than custom code in a build file. Custom logic in Maven means building and publishing an extension; it can't be local to the project. You may encounter projects that depend on extensions from long-lost open source projects, or long-lost internal projects. On one occasion, I was lucky to find a source jar for the extension in the Maven repository. It can be a nightmare. The same could happen with Gradle, since a build can depend on arbitrary libraries, but I never saw it in the wild. People depended on major open-source extensions and added their own custom code inside the build.

cyberax 2y ago
> it can't be local to the project It certainly can be, in the same repository.
- dkarl 2y ago
  When I used Maven, extensions had to be published to and pulled from a public repo. We couldn't even use the private repo that we used for the rest of our libraries, because the extension had to be loaded before Maven read the file where our private repo was configured. Whereas a Gradle build can read Groovy files straight from disk.
  - cyberax 2y ago
    > When I used Maven, extensions had to be published to and pulled from a public repo. You can just `mvn install` them locally into your local repository.
    - lihaoyi 2y ago
      You can, but why should you need to? Why can't the build tool take the plugin code directly off of disk, build it, and use it? This kind of orchestration of manual steps is what build tools are meant to be good at

chikere232 2y ago

My problem with gradle is that they keep making breaking changes for low value things like naming of options, so I have to chase deprecation warnings, and can never rely on a distro supplied gradle version Gradle devs, please get over yourself and stay backward compatible.