Hey guys,
I am also all in to reduce the scope to begin with (leaving full OSGi support
to later), but I think the OSGi manifests should be at least in line with the
rewritten jakarta.* packages / versions. At worst, we could strip the OSGi
instructions
from the manifests altogether, it is better than providing incomplete or
inconsistent
ones. Hope it makes sense. Thanks for the great feedback.
Best Regards,
Andriy Redko
FF> Hi Romain,
FF> Thanks for the feedback, and please see my comments inline below.
FF> On Sat, Nov 6, 2021 at 9:53 AM Romain Manni-Bucau <[email protected]>
FF> 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.
FF> Yes, I know maven-shade-plugin, Apache Servicemix bundles/specs projects
FF> use it to OSGi-fy(or simply fix OSGGi headers) non-OSGi jars. But I can't
FF> follow how this can help cxf-module-jarkarta.jar(using jakarta package API)
FF> to work in Karaf container short term, especially considering that Karaf
FF> ecosystem(karaf and other projects deployed in Karaf) still lingers with
FF> 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).
FF> Historically we have such specs jars from Apache Servicemix ;), and we can
FF> also add jakarta api there if needed
FF> 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.
FF> We surely can discuss it further along the track.
FF> And guys,
FF> What I want to express is that if feasible, we can get Jim's PR in if it's
FF> a good start along the track, even though it's not a full support of all
FF> features from CXF. So that we can get feedback earlier(like run JAXRS TCK
FF> and see the result). Moving forward, everyone is free to make whatever
FF> contribution on cxf-module-jarkarta jars to make CXF works in more
FF> runtimes(OSGi, SpringBoot, you name it).
FF> Just my 2 cents.
FF> Have a nice weekend!
FF> 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
>> > > >
>> > > >
>> > >
>> >
