Migrate to Gradle version catalogs

[exoego]

Closes #1989

• Definition of versions is centralized in version catalogs
• Some core lib versions can still be overridden in the same manner. See below:

# default (no override)
❯ ./gradlew compileJava                                                                
Java versions for main code: [compiler:21, release:17]
Java versions for tests: [compiler:21, release:21, launcher:21]

> Configure project :
Project version: 4.0.0-SNAPSHOT (4.0)
Release version: n/a
Development version: n/a
ORM version: 7.0.2.Final
ORM Gradle plugin version: 7.0.2.Final
Vert.x SQL Client version: 5.0.0

# core libs version override 
❯ ./gradlew compileJava -PhibernateOrmVersion=7.0.4.Final -PvertxSqlClientVersion=5.0.1
Java versions for main code: [compiler:21, release:17]
Java versions for tests: [compiler:21, release:21, launcher:21]

> Configure project :
Project version: 4.0.0-SNAPSHOT (4.0)
Release version: n/a
Development version: n/a
ORM version: 7.0.4.Final    <--- ✅ override
ORM Gradle plugin version: 7.0.2.Final
Vert.x SQL Client version: 5.0.1  <--- ✅ override

Mostly auto-transformed by gradle-version-catalog-cli which I wrote.

[DavideD]

Thanks, I will have a look at this soon

[DavideD]

Thanks a lot, looks great!
But I think something got lost in the changes.

When I run a test in the main branch, it prints:

> Configure project :
Project version: 4.0.0-SNAPSHOT (4.0)
Release version: n/a
Development version: n/a
ORM version: 7.0.2.Final
ORM Gradle plugin version: 7.0.2.Final
Vert.x SQL Client Version: 5.0.0

But after your changes, I see:

> Configure project :
Project version: 4.0.0-SNAPSHOT (4.0)
Release version: n/a
Development version: n/a

This information is quite because we tend to run Hibernate Reactive with different configurations.

Also, very nitpicky, but could you also add the issue number before the commit message? It makes my life easier when I need to track down changes.
I usually add it like this:

[#2331] Migrate to Gradle version catalogs

@sebersole Could you also have a look if this is what you had in mind when you created the issue? The approach looks good to me overall, but I don't have a lot of experience with catalogs.

Thanks a lot exoego!

[exoego]

This information is quite because we tend to run Hibernate Reactive with different configurations.

I see.
Brought back the same feature here:
https://github.com/hibernate/hibernate-reactive/pull/2331/files#diff-49a96e7eea8a94af862798a45174e6ac43eb4f8b4bd40759b5da63ba31ec3ef7R120-R126

❯ ./gradlew compileJava -PhibernateOrmVersion=7.0.4.Final -PvertxSqlClientVersion=5.0.1
Java versions for main code: [compiler:21, release:17]
Java versions for tests: [compiler:21, release:21, launcher:21]

> Configure project :
Project version: 4.0.0-SNAPSHOT (4.0)
Release version: n/a
Development version: n/a
ORM version: 7.0.4.Final    <--- ✅ 
ORM Gradle plugin version: 7.0.2.Final
Vert.x SQL Client version: 5.0.1  <--- ✅

If no override, it shows default versions defined in libs.versions.toml (version catalogs).

I initially thought it should be implemented near the place where version override is implemented.
However, realized that settings.gradle is evaluated before build.gradle hence before VersionsPlugin.
So I used rootProject.afterEvaluate in build.gradle, so the versions are shown as same as before.

[DavideD]

Superseded by #2337

@exoego, Could you have a look and let me know if it makes sense?
Thanks a lot!

[sebersole]

@sebersole Could you also have a look if this is what you had in mind when you created the issue? The approach looks good to me overall, but I don't have a lot of experience with catalogs.

Roughly, yes. This does a bit more than I had anticipated doing, not sure yet whether they are good additions or not. I can take a deeper look if you want.

I see you created an alternative PR... I'll look through that one.