Version catalog access from plugin

Help/Discuss
1

I’ve implemented a versions catalog in my system, really loving this new api. I’m wondering if it is possible to access the version catalog from inside a plugin? I’d like to detect if a catalog exists, apply some entries to various configurations.

1 Like
2

Use the version of libs.version.toml in buildSrc?

3

Yeah, that’s what I’m asking, I’ve built a plugin implementing org.gradle.api.Plugin<org.gradle.api.Project>. I can’t seem to find a way to access catalog from the project api, and I was curious if I missed something, or if there is an alternative approach to get data from the catalog into my plugin.

4

it’s not difficult
You should add this code in settings.gradle in buildSrc

dependencyResolutionManagement {
    versionCatalogs {
        libs {
            from(files("../gradle/libs.versions.toml"))
        }
    }
}

Here is my usage example

def springbootVersion = project.rootProject
                .extensions
                .getByType(VersionCatalogsExtension.class)
                .named("libs")
                .findVersion("springBoot")
                .get()
                .displayName

If you still don’t understand, you can refer to my github
my github
Good luck

1 Like
5

This is exactly what I was looking for! Thanks!!!

6

How about composite builds? Let’s say there are two builds: buildscript and example, example includes buildscript by the following declaration in its settings.gradle.kts:

pluginManagement {
    includeBuild("../buildscript")
}

All attempts to access version catalogs declared in buildscript’s settings.gradle.kts fail for me if done from inside of some org.gradle.api.Plugin located in buildscript. With the code provided above (project.rootProject.extensions.getByType(VersionCatalogsExtension.class)...) it’s only possible to get example’s version catalogs.

Is there any way to access a version catalog declared inside buildscript’s settings.gradle.kts to use it from some buildscript’s Plugin?

Update. I think I’ve got the picture - when we use constructions like project.rootProject.extensions.getByType(VersionCatalogsExtension.class)... inside plugins, the only version catalogs we can access - are those declared in the target project’s (to which we are going to apply the plugin) settings.gradle.kts. In other words, there seems to be no straightforward way to encapsulate version catalogs to be used inside plugins.

One more update. What I want to have is some automatic type-safe codebase generation allowing to add similar version catalogs from .toml files not at the Gradle’s buildscript level, but inside Gradle project’s codebase (which is usually src/main/kotlin/... or anything else linked by the sourceSet configuration). So in the case of composite builds described above, buildscript’s plugins get an access to version catalogs in an encapsulated manner regardless from what these plugins are going to be applied to eventually.

So everything I wrote above can be rephrased as: is there any Gradle plugin generating type-safe wrappers for .toml-based version catalogs and adding generated classes to project’s sources? Something like:

plugins {
  id("toml-wrappers-generator")
}

tomlWrappersGenerator {
  addTargetTomlCatalog(../dependencies.toml)
}

// Now this project has got DependenciesCatalog.kt included into its compilation sources.
7

buildSrc or composite build are totally the same here, no difference.
All you can access from the code of a plugin is the version catalog that is present in the target project.
If you make sure it is the same version catalog in both projects, you could use my hack-around in the according GitHub issue to use the type-safe accessors within the plugin code.
But other than that, you can just use the string-y API.

You can publish a version catalog though and tell the consumers to use that version catalog in their builds.
Or you can have a settings plugin that defines the version catalog and tell your consumers to apply that settings plugin to get the according version catalog.

8

Not that I’m aware of, but you can probably do it relatively easily as you can loop through the entries and then generate some accessors from them, even if that is not how the version catalogs were meant to be used. :smiley:

9

Yeah, agree - will try to do it myself - now at least I have the entire picture of how it works and what I need eventually. Thank you :slight_smile:

even if that is not how the version catalogs were meant to be used. :smiley:

In my case there is a compilation of composite builds: one for required buildscripts, one for the core codebase (which is applied as a dependency to target projects by some of buildscript plugins) and one as an example of usage. Some of dependencies are shared between these builds. I want to have one ground truth for all of my dependencies by using corresponding .toml-catalogs inside some separate dependencies folder. At the same time I don’t want end users of my Gradle plugins to place any kinds of toml version catalogs into their projects just to make the plugins work.