“I hated Gradle! Kotlin and the buildSrc Plugin made me love it.” <https://quickbirdstudios.com/blo...

# feed

[Sebastian Sellmair [JB]]

“I hated Gradle! Kotlin and the buildSrc Plugin made me love it.”

https://quickbirdstudios.com/blog/gradle-kotlin-buildsrc-plugin-android/

[Casey Brooks]

The buildSrc project is incredible for managing large, complex builds. But it’s supposed to be even easier than the article describes with “precompiled script plugins”, https://docs.gradle.org/current/userguide/kotlin_dsl.html#kotdsl:precompiled_plugins . However I’ve always seemed to struggle getting those to work, applying the available dependencies in IntelliJ, has anyone had luck getting a precompiled script plugin to work in IntelliJ?

[gildor]

Yes, I use precompiled script plugins. Tooling is not perfect, especially when you add new plugin, but the latest Idea works much better with Kotlin DSL. Anyway, even on older version it worked for me, bit sometimes required invalidate cache and restart, but after that worked fine

[Sebastian Sellmair [JB]]

Hey @Casey Brooks, I think that precompiled plugins might look simpler, but I am convinced that not only the tooling justifies the use of the buildSrc plugin. It’s also, as described in the article, all the power you gain from having “just a project/module” ☺️

[cedric]

It’s surprisingly hard to share common configuration in multiple modules in Gradle

[cedric]

Even following the instructions of the doc, I’m trying to add the bintray plug-in in my buildSrc and I’m getting a cryptic

Caused by: org.gradle.api.plugins.UnknownPluginException: Plugin [id: ‘com.jfrog.bintray’] was not found in any of the following sources:

even though that plug-in is in <https://plugins.gradle.org>

[cedric]

🤷

[gildor]

@Sebastian Sellmair [JB] but PSP created to have better tooling with type safe accessors also in plugin itself, and reduce plugin creation boilerplate. I don't see contradiction here.

[cedric]

I spent hours today trying to get something very simple to work: a configureBintray() function which takes a few strings in parameters (username, password, groupId, …)

[cedric]

and have each project call that function with their own stuff

[cedric]

Completely failed.

[cedric]

That’s the first thing I made sure worked in Kobalt.

[gildor]

@cedric Bintray plugin is the worst plugins in terms of compatibility with Kotlin DSL, everything is super dynamic, I just abandon it and just use maven-publish directly, like that:

One more reason, that Bintray plugin doesn’t use maven-publish plugin, so it cannot publish metadata

But in general it’s working, do you have problem with configuring bintray

[gildor]

Now, I’m doing this:
https://github.com/gildor/knel/blob/master/build.gradle.kts#L54

And it works with no additional plugins

[cedric]

@gildor Thanks for the tip, will try that. Do you know if it's possible to do the kind of function that I was describing above?

[gildor]

@cedric Yes, it’s possible, most tricky thing is to configure bintray tho. Maybe you have a sample, so I could take a look

[jmfayard]

@Sebastian Sellmair [JB] Your article is exactly right! For Android developpers, “Gradle” really sucks, but what “*Gradle*” means for them is actually “the overly complex Android Gradle Plugin + multiple inefficient Android build tools + the awful documentation from the Android team like those build variants that should be killed + no good support for the Kotlin DSL”

[jmfayard]

@Sebastian Sellmair [JB] now if I may do a bit of auto-promotion, you may be interested by https://github.com/jmfayard/buildSrcVersions

[cedric]

@jmfayard Nice. I don't understand how this is still not built inside Gradle. It's one of the first things I implemented in Kobalt:

$ ./kobaltw --checkVersions
New versions found:
       com.beust:klaxon:0.14
       org.testng:testng:7.0.0

[jmfayard]

@cedric I totally agree with you that it should be part of Gradle some day. And the Gradle people agree with you too as long as “some day” doesn’t mean “today”. I’m happy to fill the gap in the meantime.

[jmfayard]

As an aside, how do you solve the problem of knowing what is a stable or an unstable version?
People are really creative with how they name unstable versions but I came up with this https://github.com/jmfayard/buildSrcVersions/blob/6d1d2c29a7159329e98b1b2f545f355fcacadd05/plugin/src/main/kotlin/de/fayard/PluginConfig.kt#L21-L26

[cedric]

I notice you allow the users to set a filter to eliminate non stable versions, that’s cool, I didn’t get that far with Kobalt

[cedric]

I assume that any version coming from a non snapshot repo is stable

[jmfayard]

ah ah, that would be nice. But no, and some people even use the brainfucked logic “odd numbers are unstable, even numbers are stable”

[cedric]

You can’t really tell anyway. Even a stable version can break a working project, so the user just has to try

[jmfayard]

Yes this is why you can set define whatever you want, for example:
rejectVersionIf { isNonStable(candidate.version) && !isNonStable(currentVersion)}`
and define your own isNonStable function if my default doesn’t work