https://gradle.com/ logo
Join Slack
Powered by
Is it expected that the `VersionCatalogsExtension`...
# plugin-development
l
Is it expected that the 
VersionCatalogsExtension
is not yet available when applying a project plugin via settings plugin using 
Gradle#beforeProject
? I have multiple repos for microservices with exactly the same layout. I was planning to dedupe my build configuration by creating a settings plugin that does three things: ā€¢ Registering an external version catalog ā€¢ Including the usual subprojects ā€¢ Applying project plugins to each subprojects. The project plugins were supposed to apply dependencies from the catalog. However, when doing this as described above, I noticed that version catalogs are not accessible at this stage. Is there a better approach this?
p
How exactly do you register the version catalog? Via settings.dependencyResolutionManagement?
l
Exactly. Specifically, I'm calling 
settings.getDependencyResolutionManagement().getVersionCatalogs().register(...)
The catalog is also registered correctly and made available in the build scripts. However, it is not yet available when applying plugins in 
gradle.beforeProject()
.
Although this is run before evaluation of the project, I would expect catalogs to be available at this stage since settings should have been fully evaluated šŸ¤”
p
Yeah, can reproduce it. But I get the error message that only ext is available
It does work with lifecycle.afterProject and you should be able to apply your project plugins too
v
Might be a shortcoming or bug though. Maybe you should try to report it if there is no issue about it. šŸ¤·ā€ā™‚ļø
l
afterProject
is run after the build script and would be too late. It would prevent me from effectively using the build script.
From what I can tell after a brief look at the sources, the 
VersionCatalogsExtension
is not applied from a plugin either, so I can't guard it with a withPlugin(...). šŸ˜•
v
You could theoretically with 
withPlugin('lifecycle-base") { ... }
this is the bottom-most built-in plugin and should always be applied if any built-in plugin gets applied.
l
Interesting idea. Let me try if that does the trick. I'll file an issue regardless though.
šŸ‘Œ 1
Nope. Still fails with 
Extension of type 'VersionCatalogsExtension' does not exist.
.
Copy code
project.getPluginManager().withPlugin("lifecycle-base", ignored -> {
    VersionCatalogsExtension versionCatalogs = project.getExtensions().getByType(VersionCatalogsExtension.class);
        System.out.println(versionCatalogs.getCatalogNames());
});
Oh of course it does not work if I register other plugins myself.
p
Hm, it does work for me using the Kotlin DSl šŸ¤”
Copy code
dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        mavenCentral()
    }
    versionCatalogs {
        register("kobol") {
            from("app.softwork.kobol:catalog:0.2.16")
        }
    }
}
Copy code
gradle.lifecycle.beforeProject {
    pluginManager.withPlugin("lifecycle-base") {
        extensions.getByName("versionCatalogs")
        extensions.getByName("libs")
        extensions.getByName("kobol")
    }
}
l
Yes, but this breaks as soon as you register a plugin in 
beforeProject
. šŸ˜•
p
Does your plugin applies the 
base
plugin?
l
Transitively, yes.
t
Apparently, the extension is registered in a 
project.beforeEvaluate
so it might just be that this action actually comes later than your 
beforeProject
action.
l
In that case, I'm not sure if there is anything I can do about it because it depends on execution order of things out of my control.
v
Maybe it needs to be moved to 
beforeProject
then too. šŸ¤·ā€ā™‚ļø But would still be strange that within the 
withPlugin
it would still not work
Hm, or no, as 
beforeEvaluate
probably is before the build script gets evaluated
Yeah, sounds like you cannot do much about it šŸ˜•
l
Looking at the docs, it's the same stage.
v
Even if it is the same stage, it still has some order. And if all 
beforeProject
come before all 
beforeEvaluate
, there is probably not much you can do.
l
Both are described to run "immediately before this project is evaluated"
So it's probably just the registration order
7 Views
Open in Slack
PreviousNext
Powered by