Publish to https://plugins.gradle.org/

[Turbo87]

It would be awesome if you could publish the plugin to the Gradle Plugin Portal. Gradle lately introduced a DSL that makes it quite a bit less noisy to use buildscript plugins if they are publish to that Plugin Portal.

Instructions can be found at https://plugins.gradle.org/docs/submit

[benjamin-bader]

Hi, I'd love to be able to do it. Unfortunately we can't - there's a bug in their publishing plugin such that the presence of signature files causes the plugin to crash. Maven Central requires signed artifacts - as it give us a wider distribution, we're sticking with Maven Central for now.

The bug is being tracked at https://issues.gradle.org/browse/GRADLE-3285, although it doesn't look like any action has been taken or is being contemplated.

[Turbo87]

Hmm, too bad. Thanks for the fast reply though!

[aried3r]

Hey, I just saw that by now this plugin is indeed available on the Gradle Plugin Portal, but not in the latest version. Is this an official package from you, @benjamin-bader or unofficial?

https://plugins.gradle.org/plugin/com.getkeepsafe.dexcount

[benjamin-bader]

Yes, it's official; see #256 for details on why you shouldn't use it though. tl;dr, google doesn't publish relevant jars to Gradle's plugins portal, so even if you use the new plugins block you'll still have to add classpath dependencies like the old way.

It's outdated because I forgot to update Gradle. It isn't part of my release routine (though it should be, as long as we're going to maintain a presence there).

[aried3r]

tl;dr, google doesn't publish relevant jars to Gradle's plugins portal, so even if you use the new plugins block you'll still have to add classpath dependencies like the old way.

Hmm, how do Google's jars relate to this plugin? I'm unfamiliar with how plugins work internally, so I'd love to learn! :)

As for the classpath dependencies, I'm not using them. I can't share my works build.gradle.kts, but it looks a lot like what this app does:

Root build.gradle.kts: https://github.com/DroidKaigi/conference-app-2018/blob/f19dd63f8b691d44ba7f758d92c2ca615cdad08d/build.gradle.kts

App build.gradle.kts https://github.com/DroidKaigi/conference-app-2018/blob/f19dd63f8b691d44ba7f758d92c2ca615cdad08d/app/build.gradle.kts#L13-L24

And some configuration (or workarounds? It seems to me that this switch/case shouldn't be necessary, but it is) in settings.gradle. https://github.com/DroidKaigi/conference-app-2018/blob/f19dd63f8b691d44ba7f758d92c2ca615cdad08d/settings.gradle

I use the same in our app to get version 0.8.6 from jCenter (I believe, since it's not on the Gradle Plugin Portal), so a shortened version looks like this:

// app/build.gradle.kts
plugins {
    id("com.getkeepsafe.dexcount") version "0.8.6"
}

// settings.gradle
pluginManagement {
    repositories {
        gradlePluginPortal()
        jcenter()
    }

    resolutionStrategy {
        eachPlugin {
            switch (requested.id.id) {
                case 'com.getkeepsafe.dexcount':
                    useModule("com.getkeepsafe.dexcount:dexcount-gradle-plugin:${requested.version}")
                    break
            }
        }
    }
}

It's outdated because I forgot to update Gradle. It isn't part of my release routine (though it should be, as long as we're going to maintain a presence there).

Would be awesome! Maybe then I don't need the part in settings.gradle :)

[benjamin-bader]

It matters because dexcount depends on the google-provided Android Gradle Plugin jars. These are not available from the Gradle Plugins Portal, and unless you specifically add them to your buildscript classpath, they won't be made available and dexcount will not run.

I'm not familiar with this specific workaround that you've posted, but it appears that it would sidestep the need to add buildscript classpath dependencies because it adds jcenter into the mix.

I'll see about getting an updated build published.

[benjamin-bader]

@aried3r 0.8.6 is now available in the plugin portal