Thread
#feed
    Sebastian Sellmair [JB]

    Sebastian Sellmair [JB]

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

    Casey Brooks

    3 years ago
    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

    gildor

    3 years ago
    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]

    Sebastian Sellmair [JB]

    3 years ago
    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

    3 years ago
    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
    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>
    🤷
    gildor

    gildor

    3 years ago
    @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

    3 years ago
    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.
    gildor

    gildor

    3 years ago
    @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
    c

    cedric

    3 years ago
    @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

    gildor

    3 years ago
    @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

    jmfayard

    3 years ago
    @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”
    @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

    3 years ago
    @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

    jmfayard

    3 years ago
    @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

    3 years ago
    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
    jmfayard

    jmfayard

    3 years ago
    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

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

    jmfayard

    3 years ago
    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