4 ms·

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

by Boxxed 9y 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 9y 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 9y ago
  This may be naive but doesn't GNU Make tick all these boxes in addition to being ubiquitous?
  - kodablah 9y 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 9y 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 9y ago
        Your makefile / build script would grow so complex so as to start reimplementing maven or gradle.
      - dcow 9y ago
        What if two things share a dependency?
        na85 9y ago
        Do you mean a conflicting dependency in one of my 5 projects? If so, it's on me to pay that technical debt and fix my own crap. If the dependency doesn't conflict, then my package manager takes care of it.
        pas 9y ago
        In the JVM world it's not uncommon to have different sets of versions of the same libraries for different but dependent projects. And it's not a problem, because classloading is hierarchical and so different versions can live side by side even inside one JVM. And a lot of Java/Groovy/Scala/Kotlin libs are on Maven Central, but not packaged for let's say CentOS/Ubuntu/Debian/etc. So the package manager for JVM is Ivy (ivy2), or full Maven (which is basically ivy + a task runner).
  - dcow 9y ago
    I like make, but no. Try out gradle; it really does support complex project structures in a much more natural way than make does or even can. For example, have you ever wanted to break a large project up into subcomponents with build-time enforced dependency relationships? This is trivial with gradle but very hard/custom to do using make. gradle is aware at a domain modeling level about components of a project, their dependencies, and the implementation and interface artifacts they generate. I think this is really cool. Their native support is still evolving, so it probably can't drop-in replace more complex native builds, but a few years ago I had it building a shared c++ codebase for macOS, android-linux, and iOS. I could test the core on macOS locally as its own project. I had google-test built locally and specified as a dependency (a sibling project) rather than prebuilt and plopped in a vendor directory. And the code was mostly free of ifdef android or macos etc. because I could not only enforce separation at a project level, but also easily provide a place for platform specific glue to live (in their own sibling projects). It was really cool and would have been a lot more work without gradle.
  - rleigh 9y ago
    GNU Make has a huge amount of convention over configuration. It has hundreds of built-in pattern rules!
ataturk 9y ago
Um, no. Because Maven and Gradle share the concept of convention over configuration and you obviously weren't around for the bad old days of ant (or make) in which every company had their own weird builds. I used Gradle for years and then in my current role had to move back to Maven because that's what my employer wants and I don't miss Gradle. I was quite good at creating builds with Gradle, too. But I must concede that the points people make about it are accurate--you can't depend on having just one Gradle guru on the team and there is a lot of magic with Gradle whereas Maven is much more clear what is going on and how. Also, the point about "build flexibility"--it just doesn't come up that much. You can write shell scripts you know. I did once have a Gradle build that would install SQL Server, install our application, run all the tests, including integration tests against the live database, then tear everything down and remove it all like it was never there. I am interested in the Gradle Kotlin DSL since I also have had to accept the fact that Groovy is dying/dead now. Outside of IDEA, you can't get good Groovy IDE support anymore for example. It's dead, Jim. Kotlin lives, albeit with a sliver of market share thanks mostly to Android and the tireless efforts of JetBrains.

by Boxxed 9y ago

kodablah 9y 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 9y ago
This may be naive but doesn't GNU Make tick all these boxes in addition to being ubiquitous?
- kodablah 9y 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 9y 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 9y ago
      Your makefile / build script would grow so complex so as to start reimplementing maven or gradle.
    - dcow 9y ago
      What if two things share a dependency?
      - na85 9y ago
        Do you mean a conflicting dependency in one of my 5 projects? If so, it's on me to pay that technical debt and fix my own crap. If the dependency doesn't conflict, then my package manager takes care of it.
        pas 9y ago
        In the JVM world it's not uncommon to have different sets of versions of the same libraries for different but dependent projects. And it's not a problem, because classloading is hierarchical and so different versions can live side by side even inside one JVM. And a lot of Java/Groovy/Scala/Kotlin libs are on Maven Central, but not packaged for let's say CentOS/Ubuntu/Debian/etc. So the package manager for JVM is Ivy (ivy2), or full Maven (which is basically ivy + a task runner).
- dcow 9y ago
  I like make, but no. Try out gradle; it really does support complex project structures in a much more natural way than make does or even can. For example, have you ever wanted to break a large project up into subcomponents with build-time enforced dependency relationships? This is trivial with gradle but very hard/custom to do using make. gradle is aware at a domain modeling level about components of a project, their dependencies, and the implementation and interface artifacts they generate. I think this is really cool. Their native support is still evolving, so it probably can't drop-in replace more complex native builds, but a few years ago I had it building a shared c++ codebase for macOS, android-linux, and iOS. I could test the core on macOS locally as its own project. I had google-test built locally and specified as a dependency (a sibling project) rather than prebuilt and plopped in a vendor directory. And the code was mostly free of ifdef android or macos etc. because I could not only enforce separation at a project level, but also easily provide a place for platform specific glue to live (in their own sibling projects). It was really cool and would have been a lot more work without gradle.
- rleigh 9y ago
  GNU Make has a huge amount of convention over configuration. It has hundreds of built-in pattern rules!

ataturk 9y ago

Um, no. Because Maven and Gradle share the concept of convention over configuration and you obviously weren't around for the bad old days of ant (or make) in which every company had their own weird builds. I used Gradle for years and then in my current role had to move back to Maven because that's what my employer wants and I don't miss Gradle. I was quite good at creating builds with Gradle, too. But I must concede that the points people make about it are accurate--you can't depend on having just one Gradle guru on the team and there is a lot of magic with Gradle whereas Maven is much more clear what is going on and how. Also, the point about "build flexibility"--it just doesn't come up that much. You can write shell scripts you know. I did once have a Gradle build that would install SQL Server, install our application, run all the tests, including integration tests against the live database, then tear everything down and remove it all like it was never there. I am interested in the Gradle Kotlin DSL since I also have had to accept the fact that Groovy is dying/dead now. Outside of IDEA, you can't get good Groovy IDE support anymore for example. It's dead, Jim. Kotlin lives, albeit with a sliver of market share thanks mostly to Android and the tireless efforts of JetBrains.