> One thing we need to start removing for TomEE 10 is all the shading > operations we do on various libraries, CXF being one of them. They make >TomEE development harder and also break dependency management.
+1 - it is definitley a pain ;) Am Montag, dem 10.10.2022 um 10:28 +0200 schrieb Jean-Louis Monteiro: > Hi, > > As I mentioned, I started debugging some TCK failures with CXF, but > the > learning curve and the JAX-RS specification and CXF stack is a big of > a > challenge. > > So I also tried master because it moved to jakarta, but I have the > same > feedback and concerns that you mentioned David. I don't think it's a > good > option for TomEE 9. Maybe for 10 that would be great. > > One thing we need to start removing for TomEE 10 is all the shading > operations we do on various libraries, CXF being one of them. They > make > TomEE development harder and also break dependency management. > > -- > Jean-Louis Monteiro > http://twitter.com/jlouismonteiro > http://www.tomitribe.com > > > On Sat, Oct 8, 2022 at 5:51 PM David Blevins <[email protected] > > > wrote: > > > Just checked in on where CXF 4.0 is at in the development > > cycle. This is > > the version that implements the jakarta namespace. High level: > > > > - Still heavy development > > - No milestone releases > > - Targeting Java 17 > > - Targeting Jakarta Rest 3.0 > > > > It's a little tricky to know in which TomEE version we could use > > that. > > TomEE 9 is Java 11 and above, so the Java 17 requirement rules out > > using > > CXF 4.0 -- as does the timeline, really. TomEE 10 would be Jakarta > > 10 & > > Java 17 focused, but there we'd need Jakarta Rest 3.1, not 3.0. > > > > Given we're nearly at the finish line with TomEE 9, I suspect the > > best > > outcome for us would be that CXF 4.0 jumps to Jakarta Rest 3.1 > > (with our > > help of course). > > > > Thoughts? > > > > > > -David > > > >
smime.p7s
Description: S/MIME cryptographic signature
