Revert change in 12.1.x that puts ee# version properties in top level pom

[joakime]

Jetty version(s) 12.1.x

Jetty Environment All

Java version/vendor (use: java -version) Any

OS type/version Any

Description There is a change in the top level pom in branch jetty-12.1.x that puts all of the EE# property versions in the top level pom.

• Commit https://github.com/jetty/jetty.project/commit/5dc9a73970de125b34ed3d757457ee76b80e2d3c

https://github.com/jetty/jetty.project/blob/efc20894adc431493b92c84aad0b3115f0fd3447/pom.xml#L183-L272

This has to be undone as it doesn't play nicely with any of the versioning tools (command line, maven, IDE, dependabot, rennovate, etc) or CVE tooling.

Each of those tools works with the /jetty-ee#/ tree in isolation (as we don't want changes in /jetty-ee9/ to impact /jetty-ee10/ for example). Putting these properties in the top level pom hides them from all of those tools, and those versions cannot be updated in isolation from each other.

Also, In the future, if we go with git submodules, this change cannot exist.

This also prevents merging of jetty-12.0.x versions in a reliable way.

[janbartel]

This has to be undone as it doesn't play nicely with any of the versioning tools (command line, maven, IDE, dependabot, rennovate, etc) or CVE tooling.

Please provide a concrete example of a problem.

Each of those tools works with the /jetty-ee#/ tree in isolation (as we don't want changes in /jetty-ee9/ to impact /jetty-ee10/ for example).

Changes in jetty-ee9 are still absolutely isolated and have no impact on any other module. Nothing about this change impacts in any way the build relationship between any existing modules.

Putting these properties in the top level pom hides them from all of those tools, and those versions cannot be updated in isolation from each other.

Please provide a concrete example, and an explanation of why these tools cannot be reconfigured to refer to the top level pom properties instead.

Also, In the future, if we go with git submodules, this change cannot exist.

Not an argument for the present. Moreover, all the jetty-eeX modules already depend on properties that are declared in the top level pom, so if we do go to git submodules in the future we would have to face this problem anyway.

This also prevents merging of jetty-12.0.x versions in a reliable way.

Merging from jetty-12.0.x is already problematic, so I don't think this is a showstopper.

I'm willing to look at other solutions, but the solution is not to duplicate dependency version information.