Hi all,
thanks for your reviews. Now we should think about how we want to proceed with the PR regarding our release strategy. According to the EF project page, the next release will be 2.1, but I think a change like this shouldn‘t be part of a minor release. Maybe it makes sense to skip 2.1 and release 3.0 instead, so we can focus on the CXF removal and the Jakarta RESTful Webservice update, which seems to contain breaking changes too?
What do you think about this?
Best regards,
Tobias
Am 13.04.2021 um 08:32 schrieb Christian Kaltepoth <christian@xxxxxxxxxxxx>:
@Tobias: Thanks a lot.
@Ivar: Yes, I guess this makes sense.
Hi all,
Now that we remove stuff from Krazo, I think that the next version should be a major, i.e. 3.0.0.
NOTE: the next version of MVC will still be 2.1.
I don't see any reason why Krazo versions should align with MVC versions anyway.
Ivar
Awesome! :-)
Hi all,
great, thanks for your votes. I‘ll later open an issue to remove the CXF support. Maybe I even find some time to work on it this evening. Looks like we decided to go with option 4! :-) +1 for option 4
Hi,
+1 for option 4.
And if I'm not mistaken, it is possible to use the Krazo-RestEasy module with TomEE if users want to use the server in question.
thanks
+1 for option 4
Regards, Jonathan Sent from my iPhone Hi all,
+1 for option 4.
Best regards,
Tobias Hi,
+1 for option 4.
best Flo
Hi all,
thanks for your feedback. I actually forgot about the CXF workarounds we have in the core module TBH. And we should definitely think about them as well. Especially, because having them in the core module may not be optimal in the long-term.
So I guess we have the following options: - Leave everything as it is today (keep CXF module + workarounds in core + publish to Maven Central)
- Keep CXF module + workarounds in core module but don't publish artifacts to central anymore
- Remove CXF module but keep the CXF workaround in 'core'
- Remove CXF module and remove CXF workarounds in 'core' completely
After thinking about this a bit more, I guess that I'm actually for (4). Especially because getting rid of the complexity for the CXF workaround in the core module would be a good thing and because CXF isn't really relevant any more (except for TomEE which is a "minor player").
It would be great if you could cast a vote as well. And feel free to suggest other options if I missed one.
Christian
Hi all, I agree that CXF is taking too much effort to maintain - in my eyes OpenLiberty support made it worth it, but if that argument is gone… Is TomEE the last remaining server using CXF for Jax-RS? I’m not sure if we can just leave CXF as is and see if somebody else is willing to look into it. We have some workarounds in the core module that we might get rid of. So the testsuite for cxf will probably degrade fast once we stop actively looking at it. Maybe we can compose a list of known CXF issues on a wiki-page or something like that? This would allow us to track them and see if the situation changes sometime in the future. And it would give us something we can refer to when somebody asks about CXF. Gregor On 5 Apr 2021, at 15:17, Ivar Grimstad wrote:
Hi all, Hi Tobias,
thanks for starting this discussion.
I agree that CXF support isn't a high priority anymore. Especially, because OpenLiberty started to use RESTEasy instead of CXF.
And I also spent quite some time in the past debugging CXF issues. Unfortunately the issues I created in the CXF issue tracker are not addressed even after about 2 years (see CXF-7834 for example). And to be honest, I don't think that I want to spend even more time on it.
But I'm not completely sure if we should completely remove this module. Of course currently it is just experimental and not useable for real work application, but maybe somebody with more CXF experience will pick it up later on and help us to improve it. However, we should definitely make clear, that this module is experimental and not supported in any way.
I agree. Let's keep it in the source and make minimal updates required for it to compile. This will make it easier for anyone interested to pick it up. Whether it is CXF that includes it in their code base or someone else that wants to either contribute to Krazo or lift it out to their implementation.
Maybe we should exclude it from the published artifacts until it passes the tests though?
Hi all,
with this mail I'd like to open a discussion about the future of the
Krazo CXF integration. We talked a few minutes about that topic during
the MVC call, but decided that this is more a topic for the Krazo
mailing list.
In my opinion, we should think about dropping the CXF support in the
next major release and deprecate it in a minor release. My reasons for
this are:
- CXF seems to getting replaced in OpenLiberty by RESTEasy during the
update to Jakarta RESTful Web Services 3.0 (see
https://github.com/OpenLiberty/open-liberty/issues/11803). That means,
that the big application servers all use JAX-RS implementations we are
supporting really good and only TomEE is left with CXF, which is, in my
perception, a niche product.
- Most of our workarounds are CXF related and investigating issues costs
a lot of time because of little documentation and a really big codebase
of CXF itself.
- I tried to understand CXF Bean Validation to fix an Krazo issue and
asked for help on the mailinglist, but didn't receive a single anwser. I
don't know if it was only bad luck or if they aren't really interested
in this topic. Anyway, I think it's hard to implement and maintain an
integration for a framework where is only little information available
for deep technical questions.
So that are my two cents onto this topic. What are you thinking about this?
Best regards,
Tobias
_______________________________________________
krazo-dev mailing list
krazo-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/krazo-dev
--
_______________________________________________
krazo-dev mailing list
krazo-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/krazo-dev
-- Ivar Grimstad Jakarta EE Developer Advocate | Eclipse Foundation
Eclipse Foundation - Community. Code. Collaboration.
_______________________________________________
krazo-dev mailing list
krazo-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/krazo-dev
--
_______________________________________________ krazo-dev mailing list krazo-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/krazo-dev
_______________________________________________krazo-dev mailing listkrazo-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/krazo-dev
krazo-dev mailing list
krazo-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/krazo-dev
krazo-dev mailing list
krazo-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/krazo-dev
--
Ivar Grimstad Jakarta EE Developer Advocate | Eclipse Foundation
Eclipse Foundation - Community. Code. Collaboration.
krazo-dev mailing list
krazo-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/krazo-dev
--
_______________________________________________krazo-dev mailing listkrazo-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/krazo-dev
krazo-dev mailing list
krazo-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/krazo-dev
--
_______________________________________________
krazo-dev mailing list
krazo-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/krazo-dev
krazo-dev mailing list
krazo-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/krazo-dev
--
Ivar Grimstad Jakarta EE Developer Advocate | Eclipse Foundation
Eclipse Foundation - Community. Code. Collaboration.
krazo-dev mailing list
krazo-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/krazo-dev
--
_______________________________________________krazo-dev mailing listkrazo-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/krazo-dev
|
