4 ms·

At a previous project I decided to start fresh, swallow my pride and become friends with Gradle. Everyone of the cool Gradle guys can't be wrong, right? There

At a previous project I decided to start fresh, swallow my pride and become friends with Gradle. Everyone of the cool Gradle guys can't be wrong, right? There must just be something that hasn't "clicked" for me yet. As part of the process I analyzed some builds that used Gradle. It is a while ago now, but I think for something like 24 builds, I found 21 different ways to do it. Kotlin, Groovy and whether to use constants or not were just the beginning. Constants can be extracted and with a little help of DDG, every file can be updated to its kts version. But that is just the beginning. It seems to be a rule that every single thing must be possible to do in at least two different ways. I came out of that process convinced that, no, for most ordinary projects a lot of precious time can be saved by using Maven despite the "uglyness" of the pom. Maven encourages sticking to the standards. Every time you do something correctly it rewards you be letting you remove more configuration, and in the end you have something that works well, is fast enough, and is immediately recognizable for every experienced Java developer. Everytime I see the "elephant balancing on the ball" illustration that is sometimes used for Gradle courses I chuckle for myself and think it is perfect: It is a impressive, but one tiny mistake away from collapsing and breaking something big time.

creatonez 4y ago
> Maven encourages sticking to the standards. Every time you do something correctly it rewards you be letting you remove more configuration, and in the end you have something that works well, is fast enough, and is immediately recognizable for every experienced Java developer. I experienced the opposite, that even simple things require quite complex configuration in maven. I was shocked by how difficult shading is. Gradle and SBT gave some confusion, but a great deal less than maven.
- eitland 4y ago
  > even simple things require quite complex configuration in maven. I have used Maven on and off since around 2007/2008 sometime. Since I started taking responsibility for build setups I have realized that I think in every single case where I found unexpected complexity in Maven it could be solved by something like putting some folder or file in the place it was supposed to be all the time and delete most of the configuration. Convention over configuration is central to Maven after all and extra configuration is only necessary if you do something non standard.
  - justoreply 4y ago
    Maven is very slow in big, multi module projects. Gradle can cache module results (avoiding rebuilding), test results and can distribute build artifacts between developers
    - tehbeard 4y ago
      > and can distribute build artifacts between developers You care to elaborate on this point? Seems a bit too terse to convey whatever benefit this provides? I would have thought an artefact repo solves this?
      - justoreply 4y ago
        given a project split in several modules, we don't want to build them separately, we want to type check at compile time that everything works and we have a single build system managed by Gradle. Gradle is smart enough that if we are changing a module, we can build all the dependent ones, and only them. The cache system comes into play when someone is changing something: when a developer is updating the code locally with changes from other developers, they don't have to compile and run tests of modules they are not changing locally, as gradle is downloading automatically the changes from the build cache. * Developer 1 changes module A * code is pushed * CI pipeline is running and uploading all the artifacts (final production code, final test code, test results) * Developer 2 pull code locally * gradle find changes from the last local run, it tries to compile/run the tests of updated modules but results are downloaded from the cache, instead of running locally
        eitland 4y ago
        > Gradle is smart enough that if we are changing a module, we can build all the dependent ones, and only them. I rarely build big projects, we usually create multiple small ones instead and if necessary reuse through artifactory or something, but unless I misunderstand you, this is exactly the same as Maven does in a multi module project, isn't it? > The cache system comes into play when someone is changing something: when a developer is updating the code locally with changes from other developers, they don't have to compile and run tests of modules they are not changing locally, as gradle is downloading automatically the changes from the build cache. But why should other developers have a relation to the source of dependencies except for debugging? Isn't it better to upload the packaged jars to some kind of artifact repository at the end of their build pipeline?
- croo 4y ago
  My first experience with maven was the same. Then I learned what project structure , what plugin and dependency management it expects. I also read a 90 page long introduction book from cover to cover. I don't have problems with it since and every project I meet is familiar in an instant. I like maven.
oweiler 4y ago
I've seems hundreds of different projects using Maven and more or less every pom.xml looked the same. Onboarding took minutes. The first few Gradle projects I've seen looked completely different, one project contained more Gradle configuration than actual source code. And it becomes worse and worse, as every major Gradle version adds new stuff on top. I can also checkout an old Maven project and it will probably work with a recent Maven version. With Gradle, not so much. Breaking changes left and right...
marginalia_nu 4y ago
It's sort of clicked for me. I've managed to make something that's actually makes Gradle seem pretty impressive, I think mostly by accident. I recently refactored Marginalia's code base to a modular arrangement, and to my surprise Gradle actually does an extremely good job at dealing with this. It actually looks like a competent tool for the job. This is a great surprise for anyone who has worked with Gradle before. Once I got it all set up, each sub module has a fairly clean gradle file that is low in boiler plate and mostly just specifies dependencies and build artifacts. I can specify versions for the entire codebase in a single file, dependency management is very straight forward and it's stupidly fast do incremental re-builds. There are cases where I can not only re-compile but it will also in some circumstances run the pertinent tests all in less than a second. That said, to be honest it's still very confusing and I still don't understand how the hell Groovy works with it's looks-declarative-but-really-isn't code style. Although this is the first time I think I've begun to glimpse why Gradle exists other than to torment developers with API incompatibilities upon each (mandatory) upgrade to keep it working with the newest JVM. It's the first time I've felt the tool brought some sort of value to the code base. e.g. https://github.com/MarginaliaSearch/MarginaliaSearch/blob/master/code/services-satellite/api-service/build.gradle https://github.com/MarginaliaSearch/MarginaliaSearch/blob/ma... https://github.com/MarginaliaSearch/MarginaliaSearch/blob/master/settings.gradle https://github.com/MarginaliaSearch/MarginaliaSearch/blob/ma...
- re-thc 4y ago
  > That said, to be honest it's still very confusing and I still don't understand how the hell Groovy works with it's looks-declarative-but-really-isn't code style. The now default Kotlin syntax helps somewhat.
  - brabel 4y ago
    How?? It's exactly the same as the Groovy syntax in almost every way, specially the nested blocks which makes Groovy look declarative and that Kotlin inherited from Groovy.
    - re-thc 4y ago

creatonez 4y ago

> Maven encourages sticking to the standards. Every time you do something correctly it rewards you be letting you remove more configuration, and in the end you have something that works well, is fast enough, and is immediately recognizable for every experienced Java developer. I experienced the opposite, that even simple things require quite complex configuration in maven. I was shocked by how difficult shading is. Gradle and SBT gave some confusion, but a great deal less than maven.

eitland 4y ago
> even simple things require quite complex configuration in maven. I have used Maven on and off since around 2007/2008 sometime. Since I started taking responsibility for build setups I have realized that I think in every single case where I found unexpected complexity in Maven it could be solved by something like putting some folder or file in the place it was supposed to be all the time and delete most of the configuration. Convention over configuration is central to Maven after all and extra configuration is only necessary if you do something non standard.
- justoreply 4y ago
  Maven is very slow in big, multi module projects. Gradle can cache module results (avoiding rebuilding), test results and can distribute build artifacts between developers
  - tehbeard 4y ago
    > and can distribute build artifacts between developers You care to elaborate on this point? Seems a bit too terse to convey whatever benefit this provides? I would have thought an artefact repo solves this?
    - justoreply 4y ago
      given a project split in several modules, we don't want to build them separately, we want to type check at compile time that everything works and we have a single build system managed by Gradle. Gradle is smart enough that if we are changing a module, we can build all the dependent ones, and only them. The cache system comes into play when someone is changing something: when a developer is updating the code locally with changes from other developers, they don't have to compile and run tests of modules they are not changing locally, as gradle is downloading automatically the changes from the build cache. * Developer 1 changes module A * code is pushed * CI pipeline is running and uploading all the artifacts (final production code, final test code, test results) * Developer 2 pull code locally * gradle find changes from the last local run, it tries to compile/run the tests of updated modules but results are downloaded from the cache, instead of running locally
      - eitland 4y ago
        > Gradle is smart enough that if we are changing a module, we can build all the dependent ones, and only them. I rarely build big projects, we usually create multiple small ones instead and if necessary reuse through artifactory or something, but unless I misunderstand you, this is exactly the same as Maven does in a multi module project, isn't it? > The cache system comes into play when someone is changing something: when a developer is updating the code locally with changes from other developers, they don't have to compile and run tests of modules they are not changing locally, as gradle is downloading automatically the changes from the build cache. But why should other developers have a relation to the source of dependencies except for debugging? Isn't it better to upload the packaged jars to some kind of artifact repository at the end of their build pipeline?
croo 4y ago
My first experience with maven was the same. Then I learned what project structure , what plugin and dependency management it expects. I also read a 90 page long introduction book from cover to cover. I don't have problems with it since and every project I meet is familiar in an instant. I like maven.

oweiler 4y ago

I've seems hundreds of different projects using Maven and more or less every pom.xml looked the same. Onboarding took minutes. The first few Gradle projects I've seen looked completely different, one project contained more Gradle configuration than actual source code. And it becomes worse and worse, as every major Gradle version adds new stuff on top. I can also checkout an old Maven project and it will probably work with a recent Maven version. With Gradle, not so much. Breaking changes left and right...

marginalia_nu 4y ago

It's sort of clicked for me. I've managed to make something that's actually makes Gradle seem pretty impressive, I think mostly by accident. I recently refactored Marginalia's code base to a modular arrangement, and to my surprise Gradle actually does an extremely good job at dealing with this. It actually looks like a competent tool for the job. This is a great surprise for anyone who has worked with Gradle before. Once I got it all set up, each sub module has a fairly clean gradle file that is low in boiler plate and mostly just specifies dependencies and build artifacts. I can specify versions for the entire codebase in a single file, dependency management is very straight forward and it's stupidly fast do incremental re-builds. There are cases where I can not only re-compile but it will also in some circumstances run the pertinent tests all in less than a second. That said, to be honest it's still very confusing and I still don't understand how the hell Groovy works with it's looks-declarative-but-really-isn't code style. Although this is the first time I think I've begun to glimpse why Gradle exists other than to torment developers with API incompatibilities upon each (mandatory) upgrade to keep it working with the newest JVM. It's the first time I've felt the tool brought some sort of value to the code base. e.g. https://github.com/MarginaliaSearch/MarginaliaSearch/blob/master/code/services-satellite/api-service/build.gradle https://github.com/MarginaliaSearch/MarginaliaSearch/blob/ma... https://github.com/MarginaliaSearch/MarginaliaSearch/blob/master/settings.gradle https://github.com/MarginaliaSearch/MarginaliaSearch/blob/ma...

re-thc 4y ago
> That said, to be honest it's still very confusing and I still don't understand how the hell Groovy works with it's looks-declarative-but-really-isn't code style. The now default Kotlin syntax helps somewhat.
- brabel 4y ago
  How?? It's exactly the same as the Groovy syntax in almost every way, specially the nested blocks which makes Groovy look declarative and that Kotlin inherited from Groovy.
  - re-thc 4y ago