This message was deleted.

good for you if that helped, but the Gradle docs do contain all of that information

While that may be true, I don't like reading the official Gradle docs, as the quality is inferior by my standards. Gradle docs could be better structured; they tend to ramble on in mysterious ways. As I said, there are many intelligent people in this world, but there are not enough intelligent people who can explain things as well as Tom Overall, I am finding that using Gradle is a little bit like using Spring... there is a huge learning curve to grok things well enough to become effective, and if we don't invest in that learning, Gradle can be very unforgiving. Gradle diagnostics are abysmal, although they are slowly improving with new releases. What I like about @Tom Gregory's presentation style is that it is well structured and nicely introduces concepts. Also, he comes across with empathy by acknowledging "Gradle Was Hard..."

it's true that Gradle requires investment, but so does every other build system. what else have you used? Ant and Maven simply aren't capable of the same things that Gradle is, and sbt docs are non-existent relative to Gradle.

Yes, it took me a long time to get used to Maven, but overall the documentation is better than Gradle. Also, diagnostics are much more useful. In particular, I could make progress with Maven more on my own than having to reach out for help. Maven is a mature product designed more with robust quality in mind, whereas Gradle is designed more with clever features in mind. Gradle is more like an experimental Lamborghini, while Maven is more like a mature Utility Truck. I don't deny that Gradle has some excellent ideas, capabilities, and features, but it lacks many of the robust strengths of Maven. I would agree that the SBT docs are worse, as well as the overall developer experience, especially when things go wrong. 🙄 I have used SBT a lot more than I have used Gradle, and already I can say Gradle is superior. Scala and SBT are more like an experimental vehicle built by grad students... I don't miss Ant at all, and my days of using

make

bring back many memories of trauma. Have you ever tried to untangle build scripts using

make

written in

awk

,

sed

,

grep

,

perl

, etc.? What Gradle needs most is some design considerations that reflect the shortcomings of Gradle rather than people trying to poo-poo Maven in order to ignore Gradle's shortcomings. What Gradle needs most is for people to stop bragging about how wonderful it is and start listening to the complaints and suggested improvements. And yes, it can be traumatic reading

pom.xml

files, but I still like the idea of a static declarative structure. I am on-the-fence about build-DSLs like Scala, Groovy, Kotlin, etc. Scala is particularly bad for this, but I must admit Gradle Groovy is not as bad as Scala, and while I know Kotlin better than Groovy now, our Gradle base is all Groovy, and I want to use Kotlin with team buy-in first. Believe it or not, I have some pom.xml files with embedded Scala that work well because the Scala code is confined to very specific scripting solutions. I tried Ant in pom.xml, and that is really ugly.