This message was deleted.
# community-support
s
This message was deleted.
c
We have a settings.gradle.kts and we have a plugin that does a tiny bit of setup
Copy code
plugins {
    id("com.us.our-plugin") version "version"
}
t
Unfortunately no (AFAIK), at least not with
alias()
. But you might be able to use the TOML from a
buildSrc
(or included build) and then use the plugin without version:
Copy code
plugins {
    id("com.us.our-plugin")
}
c
Wasn't able to get alias working unfortunately, and also not able to get buildSrc working
Included build is working, but not from the classpath, I have to manually create a new plugin with the
Copy code
`java-gradle-plugin`
plugin, then register a new plugin.
So yeah 2 bits of strangeness. api/implementation doesn't matter, the plugins aren't loaded. Also buildSrc strait up can't register a plugin that the settings.gradle file will load.
So we were able to get it to work (super ugly) by moving from buildSrc to includeBuild, and from creating a new gradle plugin whose implementation was just the same as the plugin that we already had a dependency on.
v
Alias will not work due to hen-and-egg. Settings plugins should be able to bring in version catalogs, so you cannot use version catalogs before the settings plugins were applied. And
buildSrc
will also not work, it was long ago that
buildSrc
was evalutated before settings script and could be used therein, nowadays settings script is evaluated first so
buildSrc
things cannot be used. Included build in
pluginManagement
with an actual settings plugin (even if it does not do anything) in it that is applied should work, as you found out. Or you can use a TOML parser to parse the TOML file "manually" and use the version of the plugin you want to apply.
c
Thanks @Vampire, this is new to me 'nowadays settings script is evaluated first'
Do you know why plugins included via dependencies in includeBuild aren't available to settings.gradle?
And I have to
Copy code
dependencies {
    implementation(libs.our.settings.plugins)
}
gradlePlugin {
    plugins {
        register("settingsPluginHack") {
            id = "our.settings-plugin"
            implementationClass = "our.gradle.SettingsPlugin"
        }
    }
}
Where I have to re-declare a plugin with id
v
Including a build does absolutely nothing as long as you don't need something from the included build. In this case, if you don't use a settings plugin from that build, it (and its dependencies) are not added to the class path.
c
don't need something from the included build.
How do you specify a need? Other than the gradlePlugin block
Or is that/the convention plugins the only way?
v
For that case I think it is the only way. For build scripts you could also use
buildscript { dependencies { ... } }
c
hm
does that buildscript go into the includeBuild's build.gradle? Or in the root settings.gradle?
v
Instead of redeclaring the plugin you could write a simple no-op pre-compiled script plugin, just to drag the dependencies to the class path
I said "For build scripts you could also use"
1
build script != settings script
If you want the classes of an included build available in a build script without applying a plugin from that included build
c
what do you mean by no-op pre-compiled script plugin?
v
A precompiled script plugin that has no content and thus is no-op(eration). You just apply it to drag in the transitive dependencies.