James Ward and Bruce Eckel invited me to talk abou...

# feed

[cedric]

James Ward and Bruce Eckel invited me to talk about Kotlin to their Happy Path Programming podcast, and boy, did we... Hope you enjoy it! https://podcasts.apple.com/gb/podcast/8-kotlin-revisited-with-cedric-beust/id1531666706?i=1000493831847

[Stephan Schroeder]

I can very much relate with trying to learn Gradle and still not having a functioning mental model of it afterwards (even though the Kotlin DSL gets me a step further in).
I actually tried to use Kobalt instead, but the IntelliJ-plugin didn't work and nobody reacted to my bug report.

[cedric]

Sorry to hear your experience with Kobalt, @Stephan Schroeder 😞

[Stephan Schroeder]

In the talk you mentioned that you didn't have high hopes, but I certainly wish Kobalt would have made a bigger splash (The documentation might have not been good enough to bring people like me who have never been able to develop a close to complete mental model of a convention-over-configuration build system into their heads. You mention the Holywood-like Don't call us, we call you plugin-style, but on a beginners level a Kobalt config doesn't look much different from a Gradle config).
Now we can only hope that the typed nature of the Kotlin DSL will over time expel the crazy from Gradle like TypeScript does for JavaScript (of course TS adds types as carrot but introduces compiler options as sticks 🤔 We might need a big stick for Gradle as well)

[cedric]

It's unfortunate my plug-in description wasn't good enough. Kobalt has very specific extension points and you write your plug-ins against those. Gradle has no such thing, it just lets you access all ins internal structurs. In other words, you call into Gradle but Kobalt calls into you.

[cedric]

It's exactly the same model as Eclipse and IDEA

[cedric]

For example, if you want to add an entry to the classpath, you have to become a "classpath contributor". In time, Kobalt will call you and ask you to contribute your entries, and then it will add them to its (internal) classpath that it is building

[Stephan Schroeder]

but what about all the cases where you don't even need additional plugins, only the base functionality (these are my dependencies, these are my compiler options, ...). It's been like 1-2 years at this point since I looked into Kobalt, but I remember that I checked your configuration of JCommander(? or similar) and another project and I couldn't deduce the subset of stuff that I need for a new project (let's call it "hello-world-with-Sping").
So the takeaway is, maybe instead of showcasing how you configured your cool but advanced projects, show how to setup a new project with the most often used dependencies (extra points if you get a basic version of start.spring.io/ running). But I'm not looking into Kobalt currently and you haven't looked into it for 2-3 years, but I think this is what I needed (together with a working IntelliJ plugin, it wasn't buggy, it didn't even load/install) when I did look into Kobalt.
It's probably a chicken-and-egg problem, if Kobalt had become more popular, someone would have worked over the documentation and made it easier to on-board eventually.

[cedric]

I showcased JCommander because it has very few dependencies and hopefully, I documented the standard cases (where you only need compiling dependencies for src/ and test/) enough.

[cedric]

At any rate, thanks for the feedback. I'm not sure it would have made a difference, though, Gradle is the 800lbs gorilla here with dozens of developers working on it and a whole business backing it, I'm just one person doing this in their spare time 🙂