Maven-shade-plugin has transformers, some are about manifest and they rewrite the manifest with relocation rules so imports/exports can transform javax to jakarta so long story short, if desired you can have a javax code which runs in OSGi and a shade with relocation which runs in OSGi but with jakarta package for (almost) free (just a transformer to adjust if the default is not sufficient). Sounds like the best quick win to me- before the big bang.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le sam. 6 nov. 2021 à 17:59, Freeman Fang <[email protected]> a écrit : > Hi JB, > > Thanks for jumping on this. > > But to be honest, I doubt this spec feature can provide such flexibility. > > Currently in Karaf we actually expose javax packages from system bundle 0, > and those classes are from bootstrap classloader. We also use endorse > mechanism(for JDK8) and patch-module(for JDK9+) to use our revised > APIs(from karaf specs module), so in most cases, the specs in different > karaf features.xml are not installed because they have dependency="true" > flag, and the packages/versions from system bundle 0 can already meet the > OSGi resolution. We need use those APIs from bootstrap classloader and > system bundle 0 because Karaf itself needs to use some javax APIs and we > need to ensure those fundamental API classes only have one copy in the OSGi > container, otherwise we can run into ClassCastExceptions during runtime. So > AFAICS, once Karaf is started, it can work with javax. API or jakarta. API > is determined. And it's not a trivial task to keep both javax. API or > jakarta. API in a certain Karaf version,so this be a "this" or "that" > choice. > > Best Regards > Freeman > > On Sat, Nov 6, 2021 at 11:31 AM JB Onofré <[email protected]> wrote: > > > Hi guys > > > > What I proposed and started is to provide spec feature. We can have both > > javax and Jakarta spec features and use the one needed. > > > > That’s probably the most flexible approach. > > > > FYI Karaf 4.3.3 already includes specs feature repo that we can extend. > > > > Regards > > JB > > > > > Le 6 nov. 2021 à 16:17, Freeman Fang <[email protected]> a écrit > : > > > > > > Hi Romain, > > > > > > Thanks for the feedback, and please see my comments inline below. > > > > > >> On Sat, Nov 6, 2021 at 9:53 AM Romain Manni-Bucau < > > [email protected]> > > >> wrote: > > >> > > >> If it helps: maven shade plugin rewrited manifest meta using > relocation > > >> making it often osgi friendly at some header exception and several > > apache > > >> projects use that so can actually be trivial after all to run cxf + > > spec in > > >> osgi if all are relocated properly short term. > > >> > > > Yes, I know maven-shade-plugin, Apache Servicemix bundles/specs > projects > > > use it to OSGi-fy(or simply fix OSGGi headers) non-OSGi jars. But I > can't > > > follow how this can help cxf-module-jarkarta.jar(using jakarta package > > API) > > > to work in Karaf container short term, especially considering that > Karaf > > > ecosystem(karaf and other projects deployed in Karaf) still lingers > with > > > javax API for a while. > > > > > >> > > >> Long term guess geronimo would likely be a natural asf home (joined > with > > >> karaf for some serious "common" spec jars). > > >> > > > > > > > > > Historically we have such specs jars from Apache Servicemix ;), and we > > can > > > also add jakarta api there if needed > > > > > > Side note: as an cxf consumer a common cxf pain is the transitive spec > > >> jars, making them all provided or optional would make their > integration > > >> smoother so can be a low hanging fruit in this track too. > > >> > > > We surely can discuss it further along the track. > > > > > > And guys, > > > What I want to express is that if feasible, we can get Jim's PR in if > > it's > > > a good start along the track, even though it's not a full support of > all > > > features from CXF. So that we can get feedback earlier(like run JAXRS > TCK > > > and see the result). Moving forward, everyone is free to make whatever > > > contribution on cxf-module-jarkarta jars to make CXF works in more > > > runtimes(OSGi, SpringBoot, you name it). > > > > > > Just my 2 cents. > > > > > > Have a nice weekend! > > > Freeman > > > > > > > > > > > >> Le sam. 6 nov. 2021 à 14:02, Freeman Fang <[email protected]> a > > >> écrit : > > >> > > >>> Hi Guys, > > >>> > > >>> In Karaf features, we use specs bundles created from Apache > Servicemix, > > >>> which are using javax package name. Also in Apache Karaf, there is a > > >> specs > > >>> module which is also using javax package name. Given the Karaf is a > > >>> universal OSGi container and needs to support a lot more > > projects(Camel, > > >>> Activemq, OPS4J, etc) outside CXF, I don't think the ecosystem around > > >> Karaf > > >>> can move to jakarta package name that fast. > > >>> > > >>> So I think we can start the jakarta package rename work from a > > restricted > > >>> scope in CXF , say, Jim's PR can skip the OSGi support for now(as we > > >> still > > >>> have cxf released jars without the jakarta classifier which have full > > >> OSGi > > >>> support). We can see if this transformer plugin solution will work > out > > >> for > > >>> non-OSGi scenarios first. > > >>> > > >>> Moving forward, we can add OSGi support for CXF jakarta package name > > jars > > >>> once the ecosystem in OSGi matures. IMO, ideally the best time to > > support > > >>> CXF work with jakarta ee 9.1/10.0 API in OSGi container is when > jakarta > > >> ee > > >>> 9.1/10.0 API becomes the first citizen in CXF(we use jarkarta package > > >> name > > >>> in CXF but not the transform solution) > > >>> > > >>> Best Regards > > >>> Freeman > > >>> > > >>> On Sat, Nov 6, 2021 at 3:07 AM Romain Manni-Bucau < > > [email protected] > > >>> > > >>> wrote: > > >>> > > >>>> Hi, > > >>>> > > >>>> There are several Karaf users, as well as aries-jaxrs which use CXF > in > > >>>> OSGi. > > >>>> Not sure SMix will but Geronimo#specs still targets Jakarta and if > > >> needed > > >>>> we can create all the artifacts there - it is one of the reason we > > >> didn't > > >>>> stop doing specs, cause Jakarta does not care of OSGi, even if now > the > > >>>> licensing is better. > > >>>> > > >>>> Romain Manni-Bucau > > >>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog > > >>>> <https://rmannibucau.metawerx.net/> | Old Blog > > >>>> <http://rmannibucau.wordpress.com> | Github < > > >>>> https://github.com/rmannibucau> | > > >>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > >>>> < > > >>>> > > >>> > > >> > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > >>>>> > > >>>> > > >>>> > > >>>> Le sam. 6 nov. 2021 à 03:00, Andriy Redko <[email protected]> a > écrit > > : > > >>>> > > >>>>> Hi Jim, > > >>>>> > > >>>>> Thank you for working on this. I actually don't know about > > >> ServiceMix, > > >>>> but > > >>>>> over the > > >>>>> years I have seen CXF being used inside OSGi containers along with > > >>> Apache > > >>>>> Camel, as > > >>>>> well as independently, for JAX-RS / JAX-WS services. I am certain > > >> that > > >>>>> @Freeman could > > >>>>> provide more broader context. Thank you! > > >>>>> > > >>>>> Best Regards, > > >>>>> Andriy Redko > > >>>>> > > >>>>> JM> Hi Andriy, > > >>>>> JM> Sorry for the long delay about the work for > > >>>>> JM> https://github.com/apache/cxf/pull/855 > > >>>>> JM> I tried to find some information about ServiceMix's plan about > > >>>> jakarta > > >>>>> JM> namespace support. I guess ServiceMix is the only user of CXF's > > >>> OSGI > > >>>>> stuff, > > >>>>> JM> right ? Any other downstream projects which consume CXF's OSGI > > >>>> thing ? > > >>>>> > > >>>>> JM> Thanks, > > >>>>> JM> Jim > > >>>>> > > >>>>> > > >>>> > > >>> > > >> > > > > >
