This message was deleted.
# plugin-developments
Slackbot
08/15/2023, 3:41 PMThis message was deleted.
c
Chris Lee
08/15/2023, 3:45 PMVersion catalogs can be accessed from precompiled script plugins using the workaround documented here.
v
Vampire
08/15/2023, 3:46 PMOr you use the non-typesafe string-y API to access the version catalog.
f
Fabio Berta
08/15/2023, 3:47 PMYeah, I've seen those workarounds. But as they are workarounds I doesn't seem like intended usage?
v
Vampire
08/15/2023, 3:47 PMExactly, that's why you need my hack-around if you want to use the type-safe accessors
Vampire
08/15/2023, 3:48 PMThe currently supported way is the string-y API
f
Fabio Berta
08/15/2023, 3:48 PMThe string-y api doesn't work in pre-compiled plugins though?
v
Vampire
08/15/2023, 3:48 PMSure, why shouldn't it?
f
Fabio Berta
08/15/2023, 3:49 PMThat's what I understood from reading https://github.com/gradle/gradle/issues/15383, but maybe I misunderstood
Fabio Berta
08/15/2023, 3:51 PM Copy code
val libs = extensions.getByType<VersionCatalogsExtension>().named("libs")
dependencies {
implementation(libs.findLibrary("some-lib").get())
}Fabio Berta
08/15/2023, 3:51 PMsomething like this then?
v
Vampire
08/15/2023, 3:51 PMYour convention plugin cannot know what version catalog is present at runtime, as that is something that is only available when applying your plugin. So your plugin cannot know which type-safe accessors to generate, as it cannot know what version catalog will be available at application time.
My hack-around ties the version catalog present on the build building the convention plugin together with the version catalog present at application time, effectively telling Gradle that you know those will be exactly the same.
The string-y API works with plain Strings, so can fail at runtime as no type-safe accessors need to be generated for it.
f
Fabio Berta
08/15/2023, 3:52 PMYeah, I understand that and these limitations are exactly what lead to my question: is it even intended to include dependencies in these plugins?
Fabio Berta
08/15/2023, 3:52 PMOr should that be the business of the consumer, where it is exactly known what version catalogue is used
v
Vampire
08/15/2023, 3:52 PMAnd yes, something like that, I don't have the syntax in mind right now. There is probably a type-safe accessor to access that extension actually.
Vampire
08/15/2023, 3:53 PMWell, you can add dependencies from your convention plugins, that is perfectly fine. You can hard-code those dependencies in your convention plugin. Or you could yourself generate some accessors from a version catalog or similar.
Vampire
08/15/2023, 3:54 PMOr you can use the string-y API or my hack-around which both tell Gradle "I know this lib will be in that version catalog at runtime, fail if the consuming build does not provide them"
f
Fabio Berta
08/15/2023, 3:56 PMhmm yeah, I guess the real question here for me to answer is what behaviour I actually want 🤔 I'd like to publish a set of conventions plugins and use them in different projects in the company. These projects all use their own version catalogue and I'd rather not make assumptions in the plugins about what is present and what not. I guess the only feasible way would be to hardcode them. But then it's entirely possible for the consumer to include the same dependency with another version as it's not easily visible what's included. I guess more thinking is needed 🙂 thanks for your help!
đź‘Ś 1
Fabio Berta
08/15/2023, 3:58 PMIs sharing a version catalogue across projects something that people do?
v
Vampire
08/15/2023, 3:58 PMSure
c
Chris Lee
08/15/2023, 3:58 PMyes
Chris Lee
08/15/2023, 3:59 PMcatalogs can be published
v
Vampire
08/15/2023, 3:59 PMYou can for example write a settings plugin that uses the DSL to define the version catalog
Vampire
08/15/2023, 3:59 PMOr you can publish the TOML as Chris mentioned
f
Fabio Berta
08/15/2023, 4:00 PMInteresting, so basically I could create a version catalogue, use the string-y api to access the libs in there in the convention plugins, and then publish both
c
Chris Lee
08/15/2023, 4:01 PMyes. alternative (complementary) approaches to sharing dependencies include publishing a “starter” artifact that has transitive dependencies on what you wish; perhaps combined with publishing a platform to handle constraints, etc.
f
Fabio Berta
08/15/2023, 4:01 PMso if the consumers include both, it will be guaranteed to work
Fabio Berta
08/15/2023, 4:02 PMcool thanks, will investigate!