Improved: Use a version catalog

[dtrunk90]

Using a version catalog makes things easier:

• You can update a single version for multiple artifacts (e.g. Tomcat)
• You have all the artifacts and their versions at a single place separated from other stuff

See also https://docs.gradle.org/current/userguide/platforms.html

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[JacquesLeRoux]

Hi @dtrunk90,

I remember having seen that before, but completly forgot about it. Could you please update the PR, or create anew. At 1st glance, the conflicts seem a bit hard to resolve

TIA

[sonarqubecloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud

[dtrunk90]

Hi @JacquesLeRoux,

it took some hours but it's finally done.

[mbrohl]

@dtrunk90 Can you elaborate a bit more what advantages this approach brings? At first glance it seems to make things more complicate?

[JacquesLeRoux]

Hi @dtrunk90, @mbrohl ,

I must say last time I just had a glance, notably on the Gradle Page. After reading a bit more there, with a glance as the resulting code here, I indeed wonder if we need that OOTB.

@dtrunk90, I suggest to start a thread in the dev ML ([email protected]). That's what we do when we hesitate and want to make a community decision. Just few explaining words should be enough.

[JacquesLeRoux]

As a note, here is the Gradle page summary for the catalog feature:

In summary, using a catalog is always a good engineering practice as it centralizes common definitions, allows sharing of dependency versions or plugin versions, but it is an "implementation detail" of the build: it will not be visible to consumers and unused elements of a catalog are just ignored.

Again, not sure we need that, we need to deal with it in depth.