Version Catalog API: Dependency classifier can not be specified?

[jnehlmeier]

I have projects that explicitly depend on Java sources but currently it seems impossible to declare a dependency classifier in the Version Catalog API / toml file.

Expected Behavior

[versions]
some-lib-version = "1.0.0"

[libraries]
some-lib = { module = "com.example:some-lib", version.ref = "some-lib-version" }
# We need sources as well
some-lib-sources = { module = "com.example:some-lib", classifier = "sources", version.ref = "some-lib-version" }
# or possibly shorter syntax
some-lib = { module = "com.example:some-lib:sources", version.ref = "some-lib-version" }
# or possibly even shorter syntax
some-lib ="com.example:some-lib:${some-lib-version}:sources"

[melix]

This isn't a bug but a design decision: https://melix.github.io/blog/2021/03/version-catalogs-faq.html#_why_can_t_i_use_excludes_or_classifiers

[jnehlmeier]

@melix Well ok, seems reasonable. Then I would suggest updating the official documentation with all the information of your blog post. Seems like a valuable FAQ.

[tglaeser]

@melix Well ok, seems reasonable.

Is it really?

I see 2 major issues with the current limitations of version catalogs:

1. Conflicting notations compared to direct dependency declarations, see Version catalog dependencies with types resolve transitively in contrast to their String notation equivalents #20264.
2. Prevents central declaration of dependencies if each version catalog reference needs customization with each sub-project.

The design decisions as outlined in the post might or might not be warranted. I agree that the use case outlined there is valid, but so is the use case where 2..n sub-projects reverence the same library from the version catalog and it is in contrast to the idea of central declaration of dependencies if each sub-project has to apply the same constraint again in each sub-project.

It could be warranted to have the option to apply the constraint once when declaring the library or bundle within the version catalog.

[eskatos]

Thank you for your interest in Gradle!

This is a valid documentation issue that we will address.

---

@melix is correct here. The version catalog is about a collection of dependency coordinates and their versions. It is not about the configuration where the dependency is to be used nor is it about the variant that is to be selected (classifier is the legacy way of declaring a variant). That info belongs to the consumer project and there are ways to centralize that, e.g. platforms or convention plugins.

[snazy]

There is actually a bug in Gradle wrt classifiers and version catalogs.

The approach that is recommended here, like this one:

implementation(libs.orc.core) {
  artifact {
    classifier = 'nohive'
  }
}

leads to broken published Gradle module metadata - consumers of the published Gradle module metadata encounter broken dependencies. I suspect that the recommended way to specify a different artifact is broken in the same way for consumers of published Gradle module metadata.

This ugly workaround however works:

implementation("${libs.orc.core.get().module}:${libs.versions.orc.get()}:nohive")

Another ugly workaround is to not consume Gradle module metadata, like this.

See also:

• Workaround in Apache Iceberg
• IntelliJ issue

/cc @melix

[eskatos]

@snazy, care to open a separate issue about this bug?

[snazy]

#26468