mkarg commented on pull request #737: URL: https://github.com/apache/cxf/pull/737#issuecomment-751215473
> @mkarg parent pom would define the shade rules for jakarta ... I wonder what you like to gain with that and for how long? Jakarta EE 9.1 published in 2021 will already contain new functionality that MUST NOT be available from the `javax` namespace according to Oracle's brand licencing restrictions (which not only apply to the EF as a provider but also certainly to the AF as a consumer) which originally caused all this package renaming nonsense. But your shading solution would allow to write code in the `javax` namespace calling that new functionality hence leading to the caller being unaware whether he is in the Java EE world or in the Jakarta EE world, which is *exactly* what Oracle *and* the EF forbid! So once CXF supports this new functionality it MUST rewrite the `import`s -- or otherwise, *never* support this new functionality! Btw, that new functionality is the *sole* reason why I spend time into CXF currently! So why not doing it right from the start? With Jakarta EE 9 we explicitly agreed in the Jakarta WG to *only* do this sole chang e to allow all vendors to find their time for this exhausting work to *not* be forced to mix it later with the work needed for additional features. So if you defer the code changes to 9.1 you will simply have more work in less time. Hence I really doubt this decision. It would be much better to simply open a feature branch for Jakarta EE 9 and start this tedious work already. This PR can be seen as an attempt for *that*. Everything else is out of scope of *this* PR. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
