This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

I have an external gradle project containing a settings plugin as well as a project plugin (in the same module/jar). Now I consume both plugins in another project: the settings plugin in, well, settings.gradle, and the project plugin as

implementation

in my build.gradle of the included convention build project. Does the settings file share its classpath with the dependencies of the included build? Reason: I need to apply for both plugins its version, I though setting the version once would be enough.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

I’m working on a custom binary plugin and I’m running into some weird classpath issues and wondering if anyone could shed some light on the fundamental difference in ways to add plugins to the buildscript classpath.

plugins {
    kotlin("jvm") version "1.7.20"
    id("my-custom-binary-plugin")
}

If I do this approach everything works fine. However I want the plugin “my-custom-binary-plugin” to apply a bunch of Kotlin conventions so I need access to the class references. I’ve tried both

implementation("org.jetbrains.kotlin:kotlin-gradle-plugin:1.7.20")

and also

buildscript {
    repositories {
    dependencies {
        classpath("my-custom-binary-plugin:4.23.2")
        classpath("org.jetbrains.kotlin:kotlin-gradle-plugin:1.7.20")
    }
}

Both of these approaches work in the sense that I am able to find the class files just fine and apply the conventions I want to. However in both of these examples, I start to get random exceptions which point to a classpath issue in a separate library. I do not get that same classpath issue when using the plugins {} DSL in the build script, even though I would expect their classpaths to be the same but there seems to be something else going on behind the scenes in these two approaches.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

Is there some recommendations/guidance how to expose/publish artifacts from a plugin? I have a plugin that produces metadata files. There might be several of these metadata files for a single project. A few questions I'm having: 1. Should my plugin create its own publication(s) or just expose software components and leave the decision to publish to users? 2. Or should it "piggy back" on the Kotlin software component and add variants there (the metadata files are not usable without a matching kotlin jar/klib file)? 3. Should each file be its own artifact or should I "group" everything into a single zip and leave it up to consumer to loolup the "good" artifact? I hope it make sense? Looks like the Kotlin MPP plugin went with multiple publications but it could as well have been a single one with variants? How do I choose?

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.