cxf
cxf copied to clipboard
apache
Draft: Jakarta EE 9
This PR is a work-in-progress with the target to migrate CXF to Jakarta EE 9.
Any help is appreciated, as I am a Jakarta REST Committer and JAX-RS Expert Group member, but still CXF beginner... ;-)
Status: Package renames mostly done, now trying to get it build again... Some dependencies still broken.
Hi @mkarg , open question: in a lot of projects we use shade plugin to relocate and keep both javax and jakarta artifacts (since javax are and will be mainstream for some years it makes sense to keep it the default until the spec breaks something IMHO). Wouldn't it enable cxf jakarta usage without all that work just setting up shade config in the parent?
Hi @mkarg , open question: in a lot of projects we use shade plugin to relocate and keep both javax and jakarta artifacts (since javax are and will be mainstream for some years it makes sense to keep it the default until the spec breaks something IMHO). Wouldn't it enable cxf jakarta usage without all that work just setting up shade config in the parent?
I wonder how that relocation shall actually work like? Can you outline the idea?
@mkarg parent pom would define the shade rules for jakarta (https://github.com/apache/openwebbeans/blob/master/pom.xml#L353) and children would automatically create an artifact with jakarta classifier. Only trick with this is that you exclude all transitive deps to not import back a javax dependency (https://github.com/apache/openwebbeans/blob/master/src/site/apt/jakarta.apt) but this is trivially solved adding one or multiple jakarta bom doing it properly (guess we only need jaxrs and jaxws minimal poms).
Thanks for working on it, @mkarg , we have an umbrella ticket for Jakarta EE 9.0 migration (https://issues.apache.org/jira/browse/CXF-8371). There is a number of open questions with CXF dependencies (see please https://github.com/spring-projects/spring-framework/issues/25354 for example), the shading + relocation would probably cover most of the cases (we may need to look for any Class.forName usages + service loaders if any).
@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 imports -- 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 change 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.
Thanks for working on it, @mkarg , we have an umbrella ticket for Jakarta EE 9.0 migration ...
Just to make clear, I hope I will not be the only one working on this. This PR is just an exchange point for all the people interesting in contributing to this tedious and complex work, so in fact I hope that a CXF committer chimes in and turns this PR into an official CXF development branch into which we all push lots of commits to work towardss this target together.
Think the most important is not jakarta but users. So question is: what needs the most dev and maintenance, jakarta or javax - indeed i assume than forking itself is bad and too costly. My opinion is that javax will stay way more used that jakarta for years as of today. New features can be done creating fake org.apache.cxf.spec.jakarta api used for javax flavor - since compat is still a prerequisite - and shaded properly to jakarta when needed. We did it at openwebbeans for cdi 1.1 -> cdi 2 move and it was cheap and efficient. My 2 cts is that it will cost less than moving to jakarta which is a blocker for most users today (dont forget cxf is not alone in a stack and moving a full stack is rarely a success for users and libs as shown by all EE servers).
Hope it makes sense.
Think the most important is not jakarta but users.
I think you misunderstood the target of this PR: It is solely to provide Jakarta EE 9+ compatible CXF. Anything else is certainly welcome and worth a discussion, but definitively not what this PR covers. And definitively not what I can and will put efforts into, as my sole target here is to help CXF with Jakarta EE 9+ compliance. I am no a typical CXF contributor, I am just a Jakarta EE ambassador at CXF.
Also note that the Jakarta WG (including Oracle, IBM, Red Hat, and Tomitribe) decided that Jakarta EE 9.1 released in 2021 will put minimal Java level to 11, and that these companies actively plan Jakarta EE 9.1+ compatible implementations (i.e. including new jakarta.*-only APIs) compatible implementations within rather near future (Jersey will switch to Jakarta EE 9.1 within the next few months actually; the namechange is already done months ago. Hence GlassFish, hence Payara, will be jakarta-namespaced rather soon, hence their customers will do the switch eagerly and at the Jakarta EE marketing committee we working very hard to convince tool vendors and application authors to do it right now to be prepared for that very moment). The javax namespace is definitively dead, i.e. MUST NOT get extended in any way. This means, if your customers stick with javax, they soley will get bug fixes, but never new features (at least on an API level). I doubt that many customers understood that so far. They MUST rewrite their applications to javax to use any new API-level features, so that's why I really plea for branching CXF into a javax sustained branch and a jakarta branch. Everything else will not cover the actually existing needs for new features of CXF customers.
In fact I do not see much space for any other decision. Either you want to become Jakarta compliant one day, or you do not.
@mkarg which is all compatible with what I explained+proposed. Main difference is I priviledge users whereas you priviledge your personal goal. In both case you end up with a jakarta impl. Once again we see that jakarta adoption is not for today - as java 8 stayed for years before some app use java 11 and libs are still stucked to java 8. Due to lib integrations with javax and app usage jakarta will not be mainstream for tomorrow so better to keep master on what is used and in prod IMHO...in particular when we still can cover all you asked for as explained.
.... Main difference is I priviledge users whereas you priviledge your personal goal.
I actually do not have any personal goal for CXF. Certainly the CXF team decides the way to go. This PR is just a proposal, which you may gracefully drop if it is not what the CXF team wants.
Once again we see that jakarta adoption is not for today - as java 8 stayed for years before some app use java 11 and libs are still stucked to java 8.
Off-topic, but as you mentioned it: IMHO the main reason for not adopting Java 9+ is that most open source projects did not adopt either Java 9 nor multi-release JARs, so the community simply waits for that still, not vice versa. Users will adopt Java 9+ asap once all their dependencies adopt it. It is the Jakarta EE WG's intention to remove this deadlock situation by enforcing Java 11 in EE 9.1. We will see how reluctant people are once their application servers officially support Java 11 due to that synthetic pressure.
@mkarg I strongly disagree and your statements are just wrong as of today, one proof is some EE 9.1 server will still run on java 8 but point is more that the jakarta bing bang was not followed my most libs except strict EE stack and spring (which is a small part of libs - just search on github to have a light overview and keep in mind it misses all enterprise integrations) so factually you can't expect jakarta to be mainstream in the coming 5 years. What you can expect is jakarta to start to be adopted a bit in the 3 years and javax maintenance to decrease after that delay so, my opinion once again, is that for 3 years the shade relocation + cxf package for new api - it will stay small compared to the rest - is saner and then it will need to be revised depending if jakarta was actually adopted or not.
@rmannibucau Which "most libs" do you refer to? The big bang was solely targeting EE, and all EE libs did it AFAIK.
Libs like commons, play servlet support, deltaspike, log4j2 just to cite very few just for servlet (but same applies for each spec, microprofile has the same issue for ex). In other words 3rd parties didnt follow. Grep github to check it, just active projects within the year. Most servers solved it by relocation to say they support jakarta but they keep javax as mainstream. Not saying Im happy with it but it is normal/expected and must be taken into account since it is directly users not companie$$.
You are mixing things here. The Jakarta EE WG decided the big bang certainly only for EE, not for third parties; the intention was to get past this mixing situation ASAP, and the big vendors agreed to that plan, as it is the smaller pain. Now you pick third parties to proof "nobody" did -- after just few week! This is ridiculous, as we all are just in the migration phase. First, certainly third party libs are free to adopt or not adopt the new namespace as they like. Second, the Jakarta namespace is here since few weeks only, and certainly it needs months until third parties adopted it. But in the end, the javax namespace definitively is dead and there is no value in keeping it for long. Jersey for example eargerly switched the master branch (3.x), but everybody can run javax-namespaced legacy applications on a still maintained sustained branch (2.x) -- just what I proposed and what is totally fine for users. Nobody is ever allowed to extend javax in any way, so eventually every lib, and every direct implementation, like CXF, must either adopt the namespace, or deal with more and more tweaks. For example, in EE 10 there will be backwards-incompatible changes in JAX-RS, so the stack of tweaks will pile higher and higher. Anyways, I still do not see where my statements where wrong and even more, I do not understand what this discussion is all about. I already told you, CXF can do as they please, I have no strong feelings about CXF at all, so why keep insulting me?
@mkarg no no, I'm not mixing anything. EE decides the big bang -> 3rd parties must big bang too to let app still be funcitonal/work, nothing ambiguous or hard there. Makes month it had been decided and it is available with pre releases and nobody followed except spring. Just a fact. The Java 8 -> 11 move was the same (due to jigsaw) and see what happent, nobody followed for years. I'm just stating that we must keep user in mind first and guarantee them a good support level since apache is not about a company but people. Once time will allow to switch cause javax will be stable enough and less used than jakarta switch would be hurtless and enabled IMHO. Indeed a javax branch is an option but as explained before it is costly in maintenance without any single gain. Finally I never insulted you, just stated that your statements were wrong, factually, check by yourself. I understand you are involved in this big bang and want to push it - which is good - but it is brutal for everybody and at apache we think to users first so things are seen a big differently IMHO.
@mkarg just said that you were wrong saying java 8-11 point was unrelated. Guess you understood it from a EE point of view whereas my point was from a general breaking change point of view (as an example we have feedback on and we can learn from, can be the issue). So guess current status is likely to throw a mail on dev@cxf and decide if shading or fork (branch) is the best choice. Technically I know shading is way less costly to have done it a few times, always with success, but fork works as well, just requires x2 work in terms of maintenance very quickly and makes contributions harder for end users. Indeed, just my 2cts once again.
Agreed. Feel free to start that discussion on the mailing list. As I said, I am not part of CXF, just wanted to help getting Jakarta EE adopted. Good luck.
Hi folks,
I hope you had a nice christmas. Looking at our (especially enterprise) users I agree that it will take another 3-5 years to adopt Jakarta EE (if they do it, unfortunately some are just frustrated and therefore re-architecting to use a different stack). Personally I think we should support the efforts of the Jakarta EE WG to shape the future of Enterprise Java and thus I'd like to see us moving forward. However maintaining an additional branch in CXF for it (with the limited number of commiters we have) is something I wouldn't prioritize at the moment (haven't seen a single user asking for it), but I would definitely revisit this discussion in mid-2021.
Best, Dennis
Has this draft been revisited as mentioned in the last comment from @deki ?
@bogedal please check out this mailing list discussion [1] regarding JakartaEE support in CXF, thank you.
[1] https://www.mail-archive.com/[email protected]/msg17023.html
@bogedal please check out this mailing list discussion [1] regarding JakartaEE support in CXF, thank you.
[1] https://www.mail-archive.com/[email protected]/msg17023.html
I read though about 20 mails and was unable to make out the current status. I didn't find any announcements either. I just saw the agreement to use Java 11 as baseline for cxf 3.5.x which did not happen. Sadly Google will only bring users to this page and the 3.5.x changelog.
So, is there anything we (users) can already use?
@bogedal please check out this mailing list discussion [1] regarding JakartaEE support in CXF, thank you. [1] https://www.mail-archive.com/[email protected]/msg17023.html
I read though about 20 mails and was unable to make out the current status. I didn't find any announcements either. I just saw the agreement to use Java 11 as baseline for cxf 3.5.x which did not happen. Sadly Google will only bring users to this page and the 3.5.x changelog.
So, is there anything we (users) can already use?
@bmarwell the 4.0.0 / main is targeting Jakarta [1], we are not yet publishing snapshots (too many dependent projects) but we are close to have them avaible. Please refer to [2] for work in progress.
[1] https://github.com/apache/cxf/tree/main [2] https://issues.apache.org/jira/browse/CXF-8371