Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [krazo-dev] Discussion about future of krazo-cxf
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

On Mon, Apr 12, 2021 at 8:19 PM Tobias Erdle <tobi.erdle@xxxxxxxxx> wrote:
Hi all,

I created issue https://github.com/eclipse-ee4j/krazo/issues/246 for the removal of CXF and start working on it.
Hope it covers everything we need to do.

Am Mo., 12. Apr. 2021 um 10:46 Uhr schrieb Christian Kaltepoth <christian@xxxxxxxxxxxx>:
Awesome! :-)

Am Mo., 12. Apr. 2021 um 09:50 Uhr schrieb Tobias Erdle <tobi.erdle@xxxxxxxxx>:
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.

Am 12.04.2021 um 09:22 schrieb Christian Kaltepoth <christian@xxxxxxxxxxxx>:


Looks like we decided to go with option 4! :-)

Am Mo., 12. Apr. 2021 um 08:46 Uhr schrieb Ivar Grimstad <ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx>:
+1 for option 4

On Sun, Apr 11, 2021 at 4:26 PM Daniel Dias Dos Santos <daniel.dias.analistati@xxxxxxxxx> wrote:

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


Em dom., 11 de abr. de 2021 às 09:59, Jonathan Putney <jonathan@xxxxxxxxx> escreveu:
+1 for option 4

Regards,
Jonathan

Sent from my iPhone

On Apr 11, 2021, at 8:34 AM, Tobias Erdle <tobi.erdle@xxxxxxxxx> wrote:


Hi all,

+1 for option 4.

Best regards,

Tobias

Am 11.04.2021 um 13:57 schrieb Florian Hirsch <post@xxxxxxxxxxxxxxxx>:

Hi,

+1 for option 4. 

best
Flo

On 11. Apr 2021, at 12:54, Christian Kaltepoth <christian@xxxxxxxxxxxx> wrote:

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:
  1. Leave everything as it is today (keep CXF module + workarounds in core + publish to Maven Central)
  2. Keep CXF module + workarounds in core module but don't publish artifacts to central anymore
  3. Remove CXF module but keep the CXF workaround in 'core'
  4. 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


Am Di., 6. Apr. 2021 um 20:20 Uhr schrieb Gregor Tudan <gregor@xxxxxxxx>:

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, 

On Sun, Apr 4, 2021 at 12:28 PM Christian Kaltepoth <christian@xxxxxxxxxxxx> wrote:
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?
 

Other thoughts?

Christian





Am Sa., 3. Apr. 2021 um 20:08 Uhr schrieb Tobias Erdle <tobi.erdle@xxxxxxxxx>:
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@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
_______________________________________________
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 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
_______________________________________________
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. 

Back to the top