[JENKINS-75569] Upgrade Stapler from EE 9 to EE 10

[basil]

Context

Part of the following series of PRs:

• [JENKINS-75568] Upgrade Jelly from EE 9 to EE 10 jelly#140
• [JENKINS-75570] Upgrade Winstone from EE 9 to EE 10 winstone#422
• [JENKINS-75571] Upgrade core from EE 9 to EE 10 jenkins#10461
• [JENKINS-75572] Add support for Jakarta EE 10 jenkins-test-harness#941

Description

Upgrade Stapler from EE 9 to EE 10 by bumping the version numbers of the relevant libraries to match those used by Jetty 12 (EE 10) and updating the compatibility layer to match. The compatibility layer changes were implemented by throwing an exception whenever trying to invoke EE 8 functionality that is no longer supported by EE 10. In addition to being blocked on jenkinsci/jelly#140, this PR is ready for review and ready for merge from a Jenkins perspective, but it is not yet ready for merge from a CloudBees CI perspective (hence the "on hold" label).

Testing done

See jenkinsci/jenkins#10461.

[alecharp]

I understand this needs jelly pull request merged and release first, but there are a few TODO comment added in the code. Will they be implemented or kept like the ones in the code that is removed?

[basil]

These obscure corners of the API are extremely unlikely to be used in practice, and implementing them would be a lot of work—certainly more work than the easier (and better long-term option) path of migrating from EE 8 to EE 9/10. A similar strategy was used for the Acegi migration, which left some obscure corners of the API unimplemented under the assumption that nobody would ever need compatibility for them.

[olamy]

LGTM.
To avoid copy paste of version ,what about using jakartaee bom for jakarta dependencies?

https://repo.maven.apache.org/maven2/jakarta/platform/jakarta.jakartaee-bom/10.0.0/

[alecharp]

These obscure corners of the API are extremely unlikely to be used in practice, and implementing them would be a lot of work—certainly more work than the easier (and better long-term option) path of migrating from EE 8 to EE 9/10. A similar strategy was used for the Acegi migration, which left some obscure corners of the API unimplemented under the assumption that nobody would ever need compatibility for them.

Thanks. I just wanted to make sure I had the correct picture.

[basil]

To avoid copy paste of version ,what about using jakartaee bom for jakarta dependencies?

Consuming that in org.jenkins-ci.main:jenkins-bom instead of hard-coding specific versions would eliminate some copypasta, but it also has the potential to introduce problems in consumers of org.jenkins-ci.main:jenkins-bom that use things other than jakarta.servlet-api and jakarta.servlet.jsp.jstl-api. For example, jakarta.mail-api is managed in jakarta.jakartaee-bom, but we do not want core to specify a particular version of that since it is provided by a Jenkins library plugin. In short, jakarta.jakartaee-bom contains too much for us to start shipping it in org.jenkins-ci.main:jenkins-bom risk-free.