You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by GitBox <gi...@apache.org> on 2020/12/24 16:08:15 UTC
[GitHub] [cxf] mkarg opened a new pull request #737: Draft: Jakarta EE 9
mkarg opened a new pull request #737:
URL: https://github.com/apache/cxf/pull/737
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.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [cxf] rmannibucau commented on pull request #737: Draft: Jakarta EE 9
Posted by GitBox <gi...@apache.org>.
rmannibucau commented on pull request #737:
URL: https://github.com/apache/cxf/pull/737#issuecomment-750928831
@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).
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [cxf] reta commented on pull request #737: Draft: Jakarta EE 9
Posted by GitBox <gi...@apache.org>.
reta commented on pull request #737:
URL: https://github.com/apache/cxf/pull/737#issuecomment-972159530
@bogedal please check out this mailing list discussion [1] regarding JakartaEE support in CXF, thank you.
[1] https://www.mail-archive.com/dev@cxf.apache.org/msg17023.html
--
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.
To unsubscribe, e-mail: dev-unsubscribe@cxf.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [cxf] rmannibucau commented on pull request #737: Draft: Jakarta EE 9
Posted by GitBox <gi...@apache.org>.
rmannibucau commented on pull request #737:
URL: https://github.com/apache/cxf/pull/737#issuecomment-751221147
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.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [cxf] mkarg commented on pull request #737: Draft: Jakarta EE 9
Posted by GitBox <gi...@apache.org>.
mkarg commented on pull request #737:
URL: https://github.com/apache/cxf/pull/737#issuecomment-751225155
> 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.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [cxf] reta commented on pull request #737: Draft: Jakarta EE 9
Posted by GitBox <gi...@apache.org>.
reta commented on pull request #737:
URL: https://github.com/apache/cxf/pull/737#issuecomment-750941632
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).
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [cxf] bogedal commented on pull request #737: Draft: Jakarta EE 9
Posted by GitBox <gi...@apache.org>.
bogedal commented on pull request #737:
URL: https://github.com/apache/cxf/pull/737#issuecomment-971328134
Has this draft been revisited as mentioned in the last comment from @deki ?
--
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.
To unsubscribe, e-mail: dev-unsubscribe@cxf.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [cxf] mkarg commented on pull request #737: Draft: Jakarta EE 9
Posted by GitBox <gi...@apache.org>.
mkarg commented on pull request #737:
URL: https://github.com/apache/cxf/pull/737#issuecomment-751338912
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, s
o **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?
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [cxf] rmannibucau commented on pull request #737: Draft: Jakarta EE 9
Posted by GitBox <gi...@apache.org>.
rmannibucau commented on pull request #737:
URL: https://github.com/apache/cxf/pull/737#issuecomment-751242458
@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.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [cxf] mkarg commented on pull request #737: Draft: Jakarta EE 9
Posted by GitBox <gi...@apache.org>.
mkarg commented on pull request #737:
URL: https://github.com/apache/cxf/pull/737#issuecomment-751340860
I still don't get your point. *WHICH* statement was wrong?
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [cxf] mkarg commented on pull request #737: Draft: Jakarta EE 9
Posted by GitBox <gi...@apache.org>.
mkarg commented on pull request #737:
URL: https://github.com/apache/cxf/pull/737#issuecomment-751280217
> @mkarg I strongly disagree and your statements are just wrong _as of today_, ...
Good luck.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [cxf] mkarg commented on pull request #737: Draft: Jakarta EE 9
Posted by GitBox <gi...@apache.org>.
mkarg commented on pull request #737:
URL: https://github.com/apache/cxf/pull/737#issuecomment-751282046
@rmannibucau Which "most libs" do you refer to? The big bang was *solely* targeting EE, and *all* EE libs did it AFAIK.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [cxf] mkarg commented on pull request #737: Draft: Jakarta EE 9
Posted by GitBox <gi...@apache.org>.
mkarg commented on pull request #737:
URL: https://github.com/apache/cxf/pull/737#issuecomment-750925512
> 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?
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [cxf] rmannibucau commented on pull request #737: Draft: Jakarta EE 9
Posted by GitBox <gi...@apache.org>.
rmannibucau commented on pull request #737:
URL: https://github.com/apache/cxf/pull/737#issuecomment-750920514
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?
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [cxf] rmannibucau commented on pull request #737: Draft: Jakarta EE 9
Posted by GitBox <gi...@apache.org>.
rmannibucau commented on pull request #737:
URL: https://github.com/apache/cxf/pull/737#issuecomment-751284345
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$$.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [cxf] mkarg commented on pull request #737: Draft: Jakarta EE 9
Posted by GitBox <gi...@apache.org>.
mkarg commented on pull request #737:
URL: https://github.com/apache/cxf/pull/737#issuecomment-751348117
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.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [cxf] mkarg commented on pull request #737: Draft: Jakarta EE 9
Posted by GitBox <gi...@apache.org>.
mkarg commented on pull request #737:
URL: https://github.com/apache/cxf/pull/737#issuecomment-751215920
> 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*.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [cxf] rmannibucau commented on pull request #737: Draft: Jakarta EE 9
Posted by GitBox <gi...@apache.org>.
rmannibucau commented on pull request #737:
URL: https://github.com/apache/cxf/pull/737#issuecomment-751339283
@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 a
nd at apache we think to users first so things are seen a big differently IMHO.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [cxf] rmannibucau commented on pull request #737: Draft: Jakarta EE 9
Posted by GitBox <gi...@apache.org>.
rmannibucau commented on pull request #737:
URL: https://github.com/apache/cxf/pull/737#issuecomment-751342228
@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.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [cxf] mkarg removed a comment on pull request #737: Draft: Jakarta EE 9
Posted by GitBox <gi...@apache.org>.
mkarg removed a comment on pull request #737:
URL: https://github.com/apache/cxf/pull/737#issuecomment-751280217
> @mkarg I strongly disagree and your statements are just wrong _as of today_, ...
Good luck.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [cxf] deki commented on pull request #737: Draft: Jakarta EE 9
Posted by GitBox <gi...@apache.org>.
deki commented on pull request #737:
URL: https://github.com/apache/cxf/pull/737#issuecomment-751386479
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
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [cxf] mkarg commented on pull request #737: Draft: Jakarta EE 9
Posted by GitBox <gi...@apache.org>.
mkarg commented on pull request #737:
URL: https://github.com/apache/cxf/pull/737#issuecomment-751255340
> .... 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.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [cxf] rmannibucau commented on pull request #737: Draft: Jakarta EE 9
Posted by GitBox <gi...@apache.org>.
rmannibucau commented on pull request #737:
URL: https://github.com/apache/cxf/pull/737#issuecomment-751265048
@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.
----------------------------------------------------------------
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:
users@infra.apache.org
[GitHub] [cxf] mkarg commented on pull request #737: Draft: Jakarta EE 9
Posted by GitBox <gi...@apache.org>.
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:
users@infra.apache.org