Error when applying convention plugin from another convention plugin

[radoslaw-panuszewski]

It happens if the build-logic included build has 2 subprojects, each containing its own convention plugin:

• build-logic-first/.../first-convention.gradle.kts
• build-logic-second/.../second-convention.gradle.kts

The first-convention uses libs in plugins { ... } block, and the second-convention applies first-convention.

MCVE: https://github.com/radoslaw-panuszewski/typesafe-conventions-cross-convention-mcve

[v-chernyshev]

@radoslaw-panuszewski just wanted to share some rambling thoughts because I've recently addressed this problem in an in-house Gradle plugin:

• It is tricky. For this case Gradle initiates a synthetic empty build. Even though the version catalogues extension exists on the gradle-kotlin-dsl-accessors project that eventually loads the first-convention plugin, no catalogues are registered at all for this build.
• Given that the catalogues don't exist, it's impossible to dynamically instantiate the LibrariesForLibs extension that in this plugin is currently generated by hacking into the internal Gradle APIs.
• What eventually worked for me was writing my own LibrariesSourceGenerator. The project that builds first-convention.gradle.kts has full access to the catalogues, thus it knows all the aliases. For the libraries/versions/bundles it should be fine to simply replicate the shape of the accessors that Gradle generates, the generated implementation may simply defer to some lazily throwing stubs. Bonus points: complete elimination of the internal APIs usage.
• The plugins are a different story. The compiled code for first-convention.gradle.kts will use the aliases, and the plugins { ... } block will resolve the PluginDependency providers eagerly. It is, however, possible to gather the necessary information and propagate it into the custom codegen. The generated code may then instantiate and return "fake" plugin dependencies with real IDs.

I don't think I'll be able to send a PR for these changes because our in-house plugins are written in Java, but hopefully these pointers may inspire your own tweaks/fixes.

[zsoltk]

+1, I'd love to see this issue resolved