4 ms·

As much as I hate adding more build tools to the Java ecosystem this one is pretty interesting since it is entirely Java based and version controllable without

As much as I hate adding more build tools to the Java ecosystem this one is pretty interesting since it is entirely Java based and version controllable without any additional dependencies to install. Obviously this won't solve all build problems but its simplicity is attractive. (my hate for new build tools https://javarants.com/why-your-new-jvm-build-tool-is-making-things-worse-aka-use-maven-to-execute-your-build-a22ef66baa74 https://javarants.com/why-your-new-jvm-build-tool-is-making-...)

from-nibly 2y ago
My fear is upgrading/maintaining this long term. At my current company we have Gradle build files from 10 years ago and they are really fragile.
- vips7L 2y ago
  That is just Gradle. Maven works every single time.
- ethanol 2y ago
  Ten years? Try one year. I've had massive problems upgrading Gradle between consecutive major versions despite always trying to stick to the rules (as I understand them) and never using deprecated or experimental features. Maven simply doesn't have these problems. Search for Gradle discussions on HN if you're interested, the rough consensus of this site (if there is such a thing) seems to confirm my experience.
  - brnt 2y ago
    Funny, I'd've expected the opposite in the Java ecosystem. As someone entirely outside of it: why would one then use Gradle? Haven't seen a single positive post here yet.
    - vips7L 2y ago
      Gradle has faster builds due to the build daemon it uses and it has a better CLI interface. Starting a new project is just: gradle init. Some people use it just because XML == bad too.
    - zmmmmm 2y ago
      Gradle makes it incredibly fast and easy to bootstrap a simple project. Then, it's extraordinarily flexible after that in how you can use Groovy to add custom logic into how your build works. There are a lot of things I like about it. What I really hate though is that it's designed around a principle of everything happening 'magically' such that when something goes wrong it is nearly impossible to mechanistically understand what happened and how to fix it. It really leans into the most negative aspects of Groovy and amplifies them.
      - SOLAR_FIELDS 2y ago
        I usually try to gen out a graphviz dotfile of a “typical” Gradle project’s task dependency in an org to demonstrate to people how much magic happens under the hood. I often have to choose the smallest, simplest project or the graphviz engine will choke on the hundreds to thousands of nodes and dependencies used.
        kaba0 2y ago
        Aren’t you displaying each and every file? Like, gradle doesn’t have all that many tasks in a default java project.
        SOLAR_FIELDS 2y ago
        Just the default task dependency tree for a build.gradle/settings.grade. And sure, a default project might be pretty simple but add one or two plugins and it gets very unsimple very quickly. And no JVM project is using Gradle without leveraging at least a few plugins. At my last job I did this for a simple generic cron style service project (perhaps maybe 10-15 Java files, including tests) and still ended up with a task dependency tree of hundreds of nodes, due to the plugins.
      - kaba0 2y ago
        While I’m not a big kotlin fan, I do believe that using it as a config language is a good direction.
    - SOLAR_FIELDS 2y ago
      Adding onto the things that other people said: Gradle is an extremely powerful build tool. It has three tiered caching (project wide, machine wide, remote, with fallbacks), complex DAG resolution, and in general is just really good at building jvm stuff. It can handle nearly every weird way that you could possibly dream of to structure your project. It’s generally not super buggy. It’s generally pretty fast if you know what you are doing. There are years and years of optimizations built into it. It is the tool to build enterprise jvm code. If you go to a jvm shop at an adult company that isn’t stuck in 2006, they are using Gradle. The downside is that it is insanely complex, and nearly impenetrable for newbies. It’s also for the same reason pretty Perl-like (a “write-only” language)
      - kaba0 2y ago
        I would also add that there isn’t too many players in its category of general build tools. Like, sure, you can have a go-specific build tool that is more ergonomic, but it chokes the instant you add a c dependency. I guess there is only bazel and gradle that are on this level of capability, being able to compile polyglot code bases. Probably also cmake, but compared to that, gradle looks as if it was designed by God itself, even though it severely lacks in ergonomics.
        SOLAR_FIELDS 2y ago
        Yeah, I’ll also add is that while Gradle is technically a generic build tool, in practice the ecosystem realistically only makes sense to use for JVM code. All of the JS, Docker, Python, other plugins have significant issues due to only being supported/maintained by a few people. As well as Gradle giving a lot of JVM based caching for tasks set up as part of vanilla Gradle, that aren’t set up in these other ecosystems. I would argue Buildkit is also trying to be this kind of tool but is significantly less mature.
      - SpaghettiCthulu 2y ago
        I strongly disagree. Gradle is extremely buggy where it matters the most. For instance, if I cancel a build part-way through and then run it again, gradle assumes that the in-progress JavaCompile task is completed, and proceeds to generate a Jar file containing resources but no classes. To fix this, I am forced to make useless changes, or clear my entire user-level gradle cache.
    - Tainnor 2y ago
      One of the main reasons for me is that incremental compilation is essentially broken on maven, which may matter on large enough projects and if you keep waiting for CI builds. That, and the fact that anything slightly out of the ordinary that you'd want to do with maven requires a plugin - or, since most people won't bother, just extra scripts on top of maven, or no automation at all.
    - krzyk 2y ago
      because it was new and shiny, people complained that maven doesnt allow arbitrary code to be executed in build, etc. And now they end up with what Ant was like.
      - kaba0 2y ago
        If you think it’s like Ant, then you have absolutely zero understanding of gradle. Only the config step is “turing-complete”, which outputs a build graph that is cached and used to do every further step, finding the tasks that need recompilation, etc.
        krzyk 2y ago
        "only the config step" - isn't that the only step users of gradle should be interested in? If config is a code, then it makes it more complicated in the long run (people are people and will add complexity to it) - there is a reason why they work on declarative syntax.
- zmmmmm 2y ago
  The Gradle team seem to come from the school of developers that aggressively break backward compatibility as if it's a best practice. Cynically I always feel like it must give them a bump in consulting revenue each time, because it often feels gratuitous. They literally just seem to rename or shuffle things around for the fun of it. Plugins are especially brittle between versions, so I will spend hours trying to find a magic combo of gradle version, plugin version and java version that will work across a multi-project build.
- imtringued 2y ago
  Gradle breaks backwards compatibility almost every year. How do you end up with a ten year old gradle build file.
  - okr 2y ago
    You add the gradle wrapper to your project. They upgrade gradle a lot, but one doesn't have to.
Tainnor 2y ago
Maven and Gradle are entirely version controllable too. I also don't understand how your comment isn't in direct contradiction to the link you posted (which is from 2013!). At any rate, that there is no innovation in Gradle respective to maven is demonstrably false - you don't have to like these innovations, but they're there.
nogridbag 2y ago
While this looks cool, isn't using a full programming language to power your build the reason why builds become fragile? e.g. Maven just works because you're limited in what you can do.
- Osiris-Team 2y ago
  I guess that makes sense, there are pros and cons to everything. I'm trying to designing the API in such a way that power users as well as noobs can have fun with it, which is a challenging task.
diffxx 2y ago
There are some good points, but I disagree pretty strongly with some of the premises in your blog post. I ask this quite seriously: why should I care about the health of the jvm ecosystem? Unless I am oracle, how does that fit in with my personal or business goals? I know definitively that for me, personally, the quality of my build tool significantly impacts my productivity. Maven does not meet my personal bar and if I needed to use java for whatever reason, I'm not making a sacrifice to the altar of the jvm ecosystem purity and subjecting myself to maven.
- Tainnor 2y ago
  Even if you care about "the health of the ecosystem", a little bit of competition can help. If I'm not mistaken, the maven wrapper was a direct response to gradle introducing this feature first, for example, so the existence of gradle also made maven better.
oftenwrong 2y ago
Maven is the de facto standard for open source Java projects, and it still has a reserved seat at that table, but it falls short of what other build systems provide. For example, multi-module projects and incremental builds are more like bolted-on hacks in Maven 3 (I say this with great respect for the work put in by the maintainers). With rules_jvm_external, and other general usability improvements in recent years, Bazel is now quite easy to use. In a corporate context, I think Bazel is a better choice where Java is concerned. I do hope that Maven 4 will close the gap.
Osiris-Team 2y ago
Thanks! Yeah, simplicity and ease of use are definitely selling points.

from-nibly 2y ago

My fear is upgrading/maintaining this long term. At my current company we have Gradle build files from 10 years ago and they are really fragile.

vips7L 2y ago
That is just Gradle. Maven works every single time.
ethanol 2y ago
Ten years? Try one year. I've had massive problems upgrading Gradle between consecutive major versions despite always trying to stick to the rules (as I understand them) and never using deprecated or experimental features. Maven simply doesn't have these problems. Search for Gradle discussions on HN if you're interested, the rough consensus of this site (if there is such a thing) seems to confirm my experience.
- brnt 2y ago
  Funny, I'd've expected the opposite in the Java ecosystem. As someone entirely outside of it: why would one then use Gradle? Haven't seen a single positive post here yet.
  - vips7L 2y ago
    Gradle has faster builds due to the build daemon it uses and it has a better CLI interface. Starting a new project is just: gradle init. Some people use it just because XML == bad too.
  - zmmmmm 2y ago
    Gradle makes it incredibly fast and easy to bootstrap a simple project. Then, it's extraordinarily flexible after that in how you can use Groovy to add custom logic into how your build works. There are a lot of things I like about it. What I really hate though is that it's designed around a principle of everything happening 'magically' such that when something goes wrong it is nearly impossible to mechanistically understand what happened and how to fix it. It really leans into the most negative aspects of Groovy and amplifies them.
    - SOLAR_FIELDS 2y ago
      I usually try to gen out a graphviz dotfile of a “typical” Gradle project’s task dependency in an org to demonstrate to people how much magic happens under the hood. I often have to choose the smallest, simplest project or the graphviz engine will choke on the hundreds to thousands of nodes and dependencies used.
      - kaba0 2y ago
        Aren’t you displaying each and every file? Like, gradle doesn’t have all that many tasks in a default java project.
        SOLAR_FIELDS 2y ago
        Just the default task dependency tree for a build.gradle/settings.grade. And sure, a default project might be pretty simple but add one or two plugins and it gets very unsimple very quickly. And no JVM project is using Gradle without leveraging at least a few plugins. At my last job I did this for a simple generic cron style service project (perhaps maybe 10-15 Java files, including tests) and still ended up with a task dependency tree of hundreds of nodes, due to the plugins.
    - kaba0 2y ago
      While I’m not a big kotlin fan, I do believe that using it as a config language is a good direction.
  - SOLAR_FIELDS 2y ago
    Adding onto the things that other people said: Gradle is an extremely powerful build tool. It has three tiered caching (project wide, machine wide, remote, with fallbacks), complex DAG resolution, and in general is just really good at building jvm stuff. It can handle nearly every weird way that you could possibly dream of to structure your project. It’s generally not super buggy. It’s generally pretty fast if you know what you are doing. There are years and years of optimizations built into it. It is the tool to build enterprise jvm code. If you go to a jvm shop at an adult company that isn’t stuck in 2006, they are using Gradle. The downside is that it is insanely complex, and nearly impenetrable for newbies. It’s also for the same reason pretty Perl-like (a “write-only” language)
    - kaba0 2y ago
      I would also add that there isn’t too many players in its category of general build tools. Like, sure, you can have a go-specific build tool that is more ergonomic, but it chokes the instant you add a c dependency. I guess there is only bazel and gradle that are on this level of capability, being able to compile polyglot code bases. Probably also cmake, but compared to that, gradle looks as if it was designed by God itself, even though it severely lacks in ergonomics.
      - SOLAR_FIELDS 2y ago
        Yeah, I’ll also add is that while Gradle is technically a generic build tool, in practice the ecosystem realistically only makes sense to use for JVM code. All of the JS, Docker, Python, other plugins have significant issues due to only being supported/maintained by a few people. As well as Gradle giving a lot of JVM based caching for tasks set up as part of vanilla Gradle, that aren’t set up in these other ecosystems. I would argue Buildkit is also trying to be this kind of tool but is significantly less mature.
    - SpaghettiCthulu 2y ago
      I strongly disagree. Gradle is extremely buggy where it matters the most. For instance, if I cancel a build part-way through and then run it again, gradle assumes that the in-progress JavaCompile task is completed, and proceeds to generate a Jar file containing resources but no classes. To fix this, I am forced to make useless changes, or clear my entire user-level gradle cache.
  - Tainnor 2y ago
    One of the main reasons for me is that incremental compilation is essentially broken on maven, which may matter on large enough projects and if you keep waiting for CI builds. That, and the fact that anything slightly out of the ordinary that you'd want to do with maven requires a plugin - or, since most people won't bother, just extra scripts on top of maven, or no automation at all.
  - krzyk 2y ago
    because it was new and shiny, people complained that maven doesnt allow arbitrary code to be executed in build, etc. And now they end up with what Ant was like.
    - kaba0 2y ago
      If you think it’s like Ant, then you have absolutely zero understanding of gradle. Only the config step is “turing-complete”, which outputs a build graph that is cached and used to do every further step, finding the tasks that need recompilation, etc.
      - krzyk 2y ago
        "only the config step" - isn't that the only step users of gradle should be interested in? If config is a code, then it makes it more complicated in the long run (people are people and will add complexity to it) - there is a reason why they work on declarative syntax.
zmmmmm 2y ago
The Gradle team seem to come from the school of developers that aggressively break backward compatibility as if it's a best practice. Cynically I always feel like it must give them a bump in consulting revenue each time, because it often feels gratuitous. They literally just seem to rename or shuffle things around for the fun of it. Plugins are especially brittle between versions, so I will spend hours trying to find a magic combo of gradle version, plugin version and java version that will work across a multi-project build.
imtringued 2y ago
Gradle breaks backwards compatibility almost every year. How do you end up with a ten year old gradle build file.
- okr 2y ago
  You add the gradle wrapper to your project. They upgrade gradle a lot, but one doesn't have to.

Tainnor 2y ago

Maven and Gradle are entirely version controllable too. I also don't understand how your comment isn't in direct contradiction to the link you posted (which is from 2013!). At any rate, that there is no innovation in Gradle respective to maven is demonstrably false - you don't have to like these innovations, but they're there.

nogridbag 2y ago

While this looks cool, isn't using a full programming language to power your build the reason why builds become fragile? e.g. Maven just works because you're limited in what you can do.

Osiris-Team 2y ago
I guess that makes sense, there are pros and cons to everything. I'm trying to designing the API in such a way that power users as well as noobs can have fun with it, which is a challenging task.

diffxx 2y ago

There are some good points, but I disagree pretty strongly with some of the premises in your blog post. I ask this quite seriously: why should I care about the health of the jvm ecosystem? Unless I am oracle, how does that fit in with my personal or business goals? I know definitively that for me, personally, the quality of my build tool significantly impacts my productivity. Maven does not meet my personal bar and if I needed to use java for whatever reason, I'm not making a sacrifice to the altar of the jvm ecosystem purity and subjecting myself to maven.

Tainnor 2y ago
Even if you care about "the health of the ecosystem", a little bit of competition can help. If I'm not mistaken, the maven wrapper was a direct response to gradle introducing this feature first, for example, so the existence of gradle also made maven better.

oftenwrong 2y ago

Maven is the de facto standard for open source Java projects, and it still has a reserved seat at that table, but it falls short of what other build systems provide. For example, multi-module projects and incremental builds are more like bolted-on hacks in Maven 3 (I say this with great respect for the work put in by the maintainers). With rules_jvm_external, and other general usability improvements in recent years, Bazel is now quite easy to use. In a corporate context, I think Bazel is a better choice where Java is concerned. I do hope that Maven 4 will close the gap.

Osiris-Team 2y ago

Thanks! Yeah, simplicity and ease of use are definitely selling points.