Heyho, I have a plugin, that enables Gradle to handle GCP artifact repositories. I am working in a multi module project, and before I was applying this plugin to every single module. This worked fine, but had the downside that its logic ran for every module. I moved the plugin application to my root

settings.gradle.kts

and applied it in the

plugins

block. I could see it only being configured once. That was great. Unfortunately, this led to issues with my Jib setup thanks to guava version chaos. I then moved the application to

buildSrc/settings.gradle.kts

by using the "legacy" way. This made it work flawlessly for all cases. My question: Is this the "desired" way of doing it? I am asking, as gradle plugin portal calls this the "legacy" way

What do you mean when you say "I then moved the application to

buildSrc/settings.gradle.kts

by using the "legacy" way."? If you apply it in that file, it should only have an effect on the

buildSrc

build, but not on your main build where you would need the credentials set.

Like this:

buildscript {
  repositories {
    maven {
      url = uri("<https://plugins.gradle.org/m2/>")
    }
  }
  dependencies {
    classpath("io.github.bjoernmayer:artifactregistry-gradle-plugin:0.2.2")
  }
}

apply(plugin = "io.github.bjoernmayer.artifactregistryGradlePlugin")

And the "legacy" refers to applying plugins in build scripts or precompiled script plugins. There you should always use the

plugins { ... }

block except for very rare cases. If you write some plugin that applies another plugin, using the "legacy" way is fine as the legacy does not apply to that context.

I forgot to mention: The root

settings.gradle.kts

has this line:

apply(from = "buildSrc/settings.gradle.kts")

(Don't worry, I am working on cleaning this up)

😱

That is good to know. Thank you very much 🙂 As always a great help

How the "desired" way is, depends on what the actual problem was when applying to settings script. By applying to the settings script, you add the plugin to the classpath of the settings script. This makes the plugin and its dependencies be in a classloader that is a parent of the build script classloaders. So any things in that classloader wins over things in child classloaders. So I guess your problem was, that the Jib plugin needs a newer version of Guava and then failed due to some missing method error or similar. This happens as by moving your plugin to the settings script, you lost the conflict resolution as this is only per classpath. So the "desired" way in this case would be to simply add the newer version of Guava to the settings script classpath, so that the newer version that Jib needs is present in that classloader and not the older incompatible version. Alternatively, update your plugin to use newer Guava and then use that newer version.

Here is what I did: I got rid of the

apply(from

I moved the plugin application to the plugins block in root

settings.gradle.kts

I set a newer version of guava:

buildscript {
    dependencies {
        classpath("com.google.guava:guava:33.2.0-jre")
    }
}

And... et voila It just works 🙂 Beautiful