Using catalog *and* platform

Help/Discuss
1

Hibernate has a lot of dependencies to manage. I really like the idea of version-catalogs; in fact we had something similar for ages (hibernate-orm/libraries.gradle at main · hibernate/hibernate-orm · GitHub) and glad to see that has been formalized!

The catalog benefits the Hibernate build itself, but I’d also like to start producing a platform to help users/comsumers. That would lead to a LOT of duplication though. Basically, for most of the dependencies we would need an entry in both.

So I had the brilliant idea to combine these and have the platform use the version-catalog. E.g.

// settings.gradle
enableFeaturePreview("VERSION_CATALOGS")

dependencyResolutionManagement {
    versionCatalogs {
        libs {
            version( "jpa", "3.0.0" )

            alias( "jpa" ).to( "jakarta.persistence", "jakarta.persistence-api" ).versionRef( "jpa" )
            alias( "jta" ).to( "jakarta.transaction", "jakarta.transaction-api" ).version( "2.0.0")

            ...
        }
    }
}

And then,

// the platform's build.gradle
plugins {
    id 'java-platform'
}

dependencies {
    constraints {
        api libs.jpa
        api libs.jta
        ...
    }
}

However, this does not work. Specifically, while the generated module.json seems correct, the generated POM is definitely not - it does not contain any constraints.

Should this work? If so, any idea what I am doing wrong?

P.S. My other post (Sharing information between Settings and Project via Plugin) relates to this. Specifically, we need to be able to pass a version for jakarta.persistence-api at the command line to be able to scriptably test against new JPA versions. But I have not found a good solution to sharing such details between Settings and Project. Is the only option to extract that command line arg twice?

P.S.S. I ask this because the user guide does not mention they can be used together and even has a longish discussion about when to use which, largely implying that you should pick one or the other.

Thanks!

2

P.S. My other post (Sharing information between Settings and Project via Plugin ) relates to this. Specifically, we need to be able to pass a version for jakarta.persistence-api at the command line to be able to scriptably test against new JPA versions. But I have not found a good solution to sharing such details between Settings and Project. Is the only option to extract that command line arg twice?

How do you extract that command line arg?
I’d just use a Gradle property, you can set its default value in gradle.properties and overwrite it using -P. Then as mentioned in the other thread, you can simply access the Gradle property from both, the settings script and the build script easily without effort.

P.S.S. I ask this because the user guide does not mention they can be used together and even has a longish discussion about when to use which, largely implying that you should pick one or the other.

Read that longish discussion until it finishes and you see that what you say is the opposite of the truth. :slight_smile:
To quote the user guide:

In practice, your project can both use a catalog and declare a platform which itself uses the catalog:

Example 336. Using a catalog within a platform definition

plugins {
   `java-platform`
}

dependencies {
   constraints {
       api(libs.mylib)
   }
}

So yes, I’d say it should work properly.
And if you want all or almost all entries of the catalog in the platform, you can even iterate over the entries and add them automatically without duplication.

Maybe you can provide an MCVE where it does not behave like you expect?