https://kotlinlang.org logo
#feed
Title
# feed
s

Sebastian Sellmair [JB]

09/09/2019, 3:15 PM
“I hated Gradle! Kotlin and the buildSrc Plugin made me love it.” https://quickbirdstudios.com/blog/gradle-kotlin-buildsrc-plugin-android/
👍 7
c

Casey Brooks

09/09/2019, 3:47 PM
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?
g

gildor

09/09/2019, 4:25 PM
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
s

Sebastian Sellmair [JB]

09/09/2019, 6:14 PM
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” ☺️
c

cedric

09/09/2019, 9:48 PM
It’s surprisingly hard to share common configuration in multiple modules in Gradle
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
Copy code
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>
🤷
g

gildor

09/09/2019, 11:29 PM
@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.
c

cedric

09/09/2019, 11:36 PM
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, …)
and have each project call that function with their own stuff
Completely failed.
That’s the first thing I made sure worked in Kobalt.
g

gildor

09/10/2019, 1:40 AM
@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
Now, I’m doing this: https://github.com/gildor/knel/blob/master/build.gradle.kts#L54 And it works with no additional plugins
😵 1
c

cedric

09/10/2019, 2:28 AM
@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?
g

gildor

09/10/2019, 2:41 AM
@cedric Yes, it’s possible, most tricky thing is to configure bintray tho. Maybe you have a sample, so I could take a look
j

jmfayard

09/11/2019, 9:38 AM
@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”
1
@Sebastian Sellmair [JB] now if I may do a bit of auto-promotion, you may be interested by https://github.com/jmfayard/buildSrcVersions
c

cedric

09/11/2019, 11:56 AM
@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:
Copy code
$ ./kobaltw --checkVersions
New versions found:
       com.beust:klaxon:0.14
       org.testng:testng:7.0.0
j

jmfayard

09/11/2019, 4:42 PM
@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.
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
c

cedric

09/11/2019, 4:47 PM
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
I assume that any version coming from a non snapshot repo is stable
j

jmfayard

09/11/2019, 4:48 PM
ah ah, that would be nice. But no, and some people even use the brainfucked logic “odd numbers are unstable, even numbers are stable”
c

cedric

09/11/2019, 4:51 PM
You can’t really tell anyway. Even a stable version can break a working project, so the user just has to try
j

jmfayard

09/11/2019, 4:54 PM
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
6 Views