I switched from buildSrc to an includeBuild, but e...

# gradle

[hfhbd]

I switched from buildSrc to an includeBuild, but even if I create the plugins with the dsl, Gradle does not generate the PluginIdExtension anymore. With buildSrc, I could write this: plugins { latex }, now I have to use plugins { id("latex") }. Is this expected?

gradlePlugin {
    plugins {
        create("latex") {
            id = "latex"
            implementationClass = "latex.LatexPlugin"
        }
        create("plantuml") {
            id = "plantuml"
            implementationClass = "plantuml.PlantumlPlugin"
        }
    }
}

[Vampire]

Unfortunately yes.
That is one of the very few "drawbacks" when using an included build instead of buildSrc.
Also see https://github.com/gradle/gradle/issues/16929 for an issue to thumbs-up and follow.

[hfhbd]

Thanks for the issue

[eddie]

@hfhbd There's a (slightly hacky) workaround - create a no-op Settings plugin in the same project as your other build plugins and add it to the plugins block in your settings.gradle.kts .

[hfhbd]

Uh, nice workaround

[Vampire]

Oh, nice, didn't know that one yet.
The settings plugin needs to be applied by ID though of course. 😄

[julioromano]

Noob here 🙂 Can you elaborate a bit on this one?
How to create a no-op settings plugin? Is it just an empty xxx.gradle.kts file?
To which settings file should it be applied? The main project settings file? Or the included builds settings file?

[Vampire]

xxx.settings.gradle.kts and main build

[julioromano]

Thanks, but I see no accessors, is it perhaps because my included build is a multi project build?

[julioromano]

i put a settings plugin in both the projects in the picture and included them from the main projects settings file.

I can now use static accessors for those settings plugin but not for the other build plugins

[Vampire]

Yes, the settings plugin must be in the same JAR as the others. That's the point of the hack, that the settings plugin usage puts the plugins on the class path. It might also work if you add a dependency on the build project to the settings project, probably even runtimeOnly

[Vampire]

That dummy settings plugin has to be applied by string id and I guess it also only works for project plugins, not other settings plugins, but I might be wrong, didn't try that

[hfhbd]

I will upload my implementation, so you could take a look if you want 🙂

[julioromano]

Oh it does work, in case of a multi project included build you need to add a no-op settings plugin in each subproject you want static accessors to be generated for

[julioromano]

but it seems that if the name of a build plugin includes a hyphen - then the static accessor won’t be generated correctly, is this a known issue?

[julioromano]

some.build.plugin.gradle.kts --> Works
some.build-plugin.gradle.kts --> Doesn’t work

[hfhbd]

yes: https://github.com/gradle/gradle/issues/22180

[hfhbd]

Oh you mean in the name, nope, this should be a valid package name

[julioromano]

yes, the filename of the build plugin

[julioromano]

I’ve tried to apply this workaround more broadly to my project but it seems to fail sometimes when the build plugin names are “too long”.

By “too long” i mean lots of dots e.g. some.build.plugin.blah.blah.gradle.kts

[julioromano]

Fails with: Script compilation error: some.build.plugin.blah.blah ^ Unresolved reference: blah

[hfhbd]

you could put you sripts in foders matching your names, like you do in Java/Kotlin

[hfhbd]

JFYI: I uploaded my sample: https://github.com/hfhbd/latex-plantuml-gradle-plugin

[julioromano]

Perhaps the difference is that I’m trying to do it with convention plugins you instead are creating fully fledged plugins

[hfhbd]

Yeah, I like classes and tests more than scripting (and user experience is harder)

[Vampire]

Shouldn't make a difference though and I don't think name length should be an issue

[julioromano]

ooohhhh then it’s me that don’t know how to apply the backticks correctly 😛

[julioromano]

lemme try again

[Vampire]

Yeah, I like classes and tests more than scripting (and user experience is harder)

You can test precompiled script plugins the same as usual plugins. Precompiled script plugins are mainly just syntactic sugar.
And user experience should also be identical.

[Vampire]

ooohhhh then it’s me that don’t know how to apply the backticks correctly 😛

Kotlin does not like hyphens in identifiers, but using the backticks you can "quote" it and use it anyway, for example for generated things. But I'd usually try to avoid them as it degrades readability.

[julioromano]

My generated PluginAccessors.kt contains references to old plugin names (before I renamed them) so I suspect there might be some caching issue here

[Vampire]

Refresh the Gradle project and then navigate to it again.

[julioromano]

I’m giving up, there’s too many random errors popping up when trying to fiddle with these convention plugins. I’m now getting:

Execution failed for task ':demo:hiltAggregateDepsDebug'.
> A failure occurred while executing dagger.hilt.android.plugin.task.AggregateDepsTask$WorkerAction
   > 'java.lang.String com.squareup.javapoet.ClassName.canonicalName()'

Which makes little sense to me, given I’ve only renamed a Gradle convention plugin to trigger this.
I’ve given this a chance, but I’ll rather keep the id("...") syntax and live with it. Thank you all for chiming in!