This message was deleted.

The extension will only be present if there's a catalog. So my guess is that there's none.

it seems that the extension is not available yet in build scripts that apply my custom plugin in a setting like

configure(subprojects - project('elasticsearch-log4j')) {
  /*
   * All subprojects are java projects using Elasticsearch's standard build
   * tools.
   */
  apply plugin: 'elasticsearch.build'
}

the

VersionCatalogsExtension

exposes a realized catalog

I just want to consume an existing catalogue I have defined in my settings file

then it should be visible 🤔

that ugly workaround on defering acccessing version catalogue extension actually works:

var checkstyleDependencyProvider = project.provider(
                () -> project.getExtensions().getByType(VersionCatalogsExtension.class).named("buildLibs").findLibrary("checkstyle").get().get()
        );
        dependencies.addProvider("checkstyle", checkstyleDependencyProvider);

🤮

this would imply your plugin is applied before the extension is added. I'm not sure how you managed to do that 😄

I'm a pro

don't do this at home

maybe. I will try to reproduce that in a small example project first

I recall it was complicated, and if I recall properly, it's once settings are evaluated

I have a closer look and try creating a reproducible example to raise a ticket 🙂

this should be quite early, because catalogs can be used in the plugins block

I think with my sample configuration snippet above of configuring subprojects this breaks that

Are you sure you tried to get it from the correct extensions? Most time I have seen that extension not be present was because someone just used unqlified

extensions

and thus tried to get it from a task, instead of from the project.

very good point

yeah that was one thought too but in my example its explicit. I'm just writing the bug report. and the minimum example snippet that shows the problem is:

// this works!
def versionCatalogRoot = extensions.getByType(VersionCatalogsExtension).named("buildLibs")
println(versionCatalogRoot.findLibrary("checkstyle").get().get())

subprojects {
    // this throws "Extension of type 'VersionCatalogsExtension' does not exist."
    def versionCatalog = extensions.getByType(VersionCatalogsExtension).named("buildLibs")
    println(versionCatalog.findLibrary("checkstyle").get())
}

can you avoid the use of

subprojects

?

yeah thats what I will do I think to unblock me. Will create a ticket anyhow

subprojects/allprojects is always full of surprises... that said, I still have to find a replacement for when you use an init script which needs to interact with arbitrary projects

yeah I'm in the process of moving away from them but it takes time 🙂

no judgement here

just getting our codebase to configuration-cache compliant is a task for months (/ or years) :P

don't tell me about this. Micronaut is full of tricks which would probably explode with the CC.

yeah our integration test infrastructure for managing elasticsearch nodes in any possible way is full of garbage

magic

gives you a job for years 😄

to close the loop... https://github.com/gradle/gradle/issues/21191 now I need to rewrite my build scripts in the mean time