This message was deleted.

this would be solvable with a variable when using the version catalog API; don’t see how the TOML file could address this (short of manually ensuring that the dependencies line up).

Do you have an example of what this could look like with a variable?

In settings.gradle.kts:

dependencyResolutionManagement {
    versionCatalogs {
        create("libs") {
            val xVer = "1.1.4"
            version("xVer", xVer)
            library("xLib", "org.x", "lib").versionRef("xVer")
            library("yLib", "org.y:lib:y.${xVer}")
        }
    }
}

Catalog will only give you recommendations either way, so if you have several dependencies moving in lockstep you'll need to either use strict versions in catalog (which's not recommended for use in libraries) or platform alongside. Platform of course could use catalog itself.

Thank you!

the only way I found is to use

VersionCatalogExtension

on projects

yeah i guess augmenting it is what i’m unsure how to do

i'm not sure if resolution strategy or just a local platform would be easiest way in your case iirc you could just use

dependencyResolutionManagement { versionCatalogs { create("libs") { version("some-alias", "x.y.z"); version ("another-alias", "w.x.y.z") } } }

alongside autoimport from

libs.versions.toml

and then add another subproject with

java-platform

plugin and adding relevant dependencies like

dependencies { constaints { api(libs.fisrt.dep) ; api(libs.second.dep) } }

ah yeah, no worries about publishing here

just sharing some pitfalls i already checked for myself 😁

Another option might be too use a virtual platform to align the versions to also make sure they don't become different by conflict resolution. See the chapter about version alignment in the user guide.

Thank you all. In the interest of getting us cut over to version catalogs quickly I’ve opted to do a dumb hack where I just throw an exception at build time if the versions of the 2 libs don’t match. These libs haven’t been updated in 7 months so it’s probably fine for now. Our long-term solution is going to be platform. I hadn’t really considered the benefits of using a platform here but your points have been great.

in a large project I work on, I create a platform based on the version catalog https://gradle-community.slack.com/files/U019L3NM4PK/F036U1L6HGE/build.gradle.kts.kt

^ this is exactly what i was thinking. Thanks for sharing code to achieve it. I was imagining it being much more work.

if you have naming convention for other boms/platforms you can expand @ephemient's fragment to put non-boms in constraints and boms into dependencies (wrapping them as platform)

BOM/platform dependencies require

javaPlatform {
    allowDependencies()
}

so that they can be added as normally dependencies and not constraints, as you should be able to find in the documentation

Yeah, I know about

javaPlatform.allowDependencies()

. And the same bom in dependencies and constraints have different semantics.

dependencies { api(platform(libs.jackson.bom)) }

will effectively add constraints from it to your platform and

dependencies { constraints { api(platform(libs.jackson.bom)) } }

will constraint bom itself but wouldn't add its contents to constraints. In case of publishing pom would have something like

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>your.group.id</groupId>
      <artifactId>artifact.id</artifactId>
      <scope>compile</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

which does seem wrong tbh. IIRC maven doesn't like unversioned deps in

dependencyManagement

section though I couldn't point where I read that.