“I hated Gradle! Kotlin and the buildSrc Plugin made me love it.” https://quickbirdstudios.com/blog/gradle-kotlin-buildsrc-plugin-android/

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?

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

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” ☺️

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

@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.

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 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 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?

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

@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 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

@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.

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

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

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

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