Enforce dependency versions over version catalog

Help/Discuss
1

Hello everyone,

I have a project which provides a version-catalog and is consumable via an artifact.

In the version-catalog there is a libs.versions.toml, which is defined in its build.gradle:

catalog {
  versionCatalog {
    from(files("./gradle/libs.versions.toml"))
  }
}

The consumers of this catalog define in the settings.gradle:

dependencyResolutionManagement {
  versionCatalogs {
    create("libs") {
      from("group:version-catalog:1.0")
    }
  }
}

And use the dependencies like:

plugins {
  alias(libs.plugins.springDependencyManagement)
}

dependencies {
  implementation(libs.mapstruct)
}

Unfortunately, I now have dependencies which import old dependencies and I want to enforce certain versions.

I would actually do it like this:

configurations.configureEach {
    resolutionStrategy {
        forcedModules = [
                'org.springframework:spring-webmvc:6.1.3',
                'ch.qos.logback:logback-core:1.4.14',
                'ch.qos.logback:logback-classic:1.4.14'
        ]
    }
}

If I define this configuration in the projects that also consume the catalog, it works.

However, if I define this configuration in the version catalog, it does not work for the consumers of the catalog.

Is there any way to define this in the catalog without having to duplicate this config in every project? I seem to be overlooking some configuration/possibility.

Thank you very much for your help!

2

A version catalog does not directly influence any resolution and does not have any way to do so.
You can also not put classifiers in a version catalog, or mark an entry as platform.
A version catalog is like the name suggests just a catalog of coordinates and versions that you can pick from in a type-safe manner and without invalidating unrelated tasks when changing a version.

You could probably create an adjacent plugin that does this configuration and that the users should apply then.

Or you release a platform alongside your version catalog which usually is the way to control versions of transitive dependencies. Manipulating resolution strategies for version control is usually not really the appropriate tool

Btw. as you example showed the Spring Dependency Management plugin, you should replace that. It is an obsolete relict from times when Gradle did not have built-in BOM support, by now does more harm than good, and even the maintainer of that plugin recommends not to use it anymore, but the built-in BOM support using platform(...).

3

Thank you very much for your detailed answer and your effort.
Also the hint with the plugin. I will have a look at it.

If you have a buy me a coffee link, please feel free to share it with me. :slight_smile:

4

PayPal.Me, thanks. :slight_smile: