apache
[CXF-8371]:initial/experimental jakarta ee9 support with eclipse transformer
Thanks for doing this work @jimma , I think if we just scope it to rewriting packages in binary, it should work. There are 3 concerns which I would like to hear your opinion:
- Rewriting OSGi manifests may require a lot of efforts since we may need to adjust the version or version range. The way we may tackle it is to inspect all manifests and prepare the GAV map (the keys) by script. It should be more or less clear what the replacement patterns should be.
- Rewriting POM files needs more than just CXF artifacts, I think we need to bump all
jakartadependencies to correct versions and/or do eliminate ofjavaxartifacts in favor ofjakarkaartifacts if we did not bring the replacement yet. - Last but not least, it would be great to make at least some sanity checks for the artifact produced. I am thinking about Jakarta TCKs (the subset of), we would need to run it anyway at some point, so earlier we have it, better.
Do you think those are valid concerns? What are your thoughts? Thank you!
Thanks for doing this work @jimma , I think if we just scope it to rewriting packages in binary, it should work. There are 3 concerns which I would like to hear your opinion:
- Rewriting OSGi manifests may require a lot of efforts since we may need to adjust the version or version range. The way we may tackle it is to inspect all manifests and prepare the GAV map (the keys) by script. It should be more or less clear what the replacement patterns should be.
I actually didn't think of OSGI manifest. Can you please point me the code how does CXF generate OSGI manifest now? Or some quick transformation example of OSGI for me to understand what we need to do ?
- Rewriting POM files needs more than just CXF artifacts, I think we need to bump all
jakartadependencies to correct versions and/or do eliminate ofjavaxartifacts in favor ofjakarkaartifacts if we did not bring the replacement yet.
Yes. This is the major part work of transformation. I created the https://github.com/jimma/cxf/blob/ee9/ee9/src/main/resources/gav.map to provide the javax artifact to jakarta artifact replacement information. These javax artifacts will be all replaced with jakarta artifacts if these are defined in this mapping rule file.
- Last but not least, it would be great to make at least some sanity checks for the artifact produced. I am thinking about Jakarta TCKs (the subset of), we would need to run it anyway at some point, so earlier we have it, better.
That's exactly what we should do for the next step. We can start with some jakarta ee9 smoke tests first and later run against with Jakarta jaxws standalone TCK.
Do you think those are valid concerns? What are your thoughts? Thank you!
Thanks for you valuable review and input for this topic. Another thing I am not sure is : to transform cxf artifacts, should we have some subset of cxf artifacts to transform first instead of transforming all the things ? Should we draft some work plan to get this done step by step ?
@jimma thank you, regarding your questions:
Another thing I am not sure is : to transform cxf artifacts, should we have some subset of cxf artifacts to transform first instead of transforming all the things ?
Definitely, I believe Romain also suggested that on the mailing list, we could try JAX-RS first fe, and I could take care of TCK part, since we did it for Java EE, it should be pretty straightforward for Jakarta EE (same repo but another branch).
I actually didn't think of OSGI manifest. Can you please point me the code how does CXF generate OSGI manifest now? Or some quick transformation example of OSGI for me to understand what we need to do ?
It is done by the plugin, maven-bundle-plugin, see please https://github.com/apache/cxf/blob/master/parent/pom.xml#L630, the typical MANIFEST.MF entry looks like:
Import-Package: javax.wsdl;resolution:=optional,javax.wsdl.extensions;
resolution:=optional,javax.wsdl.extensions.http;resolution:=optional,
javax.xml.bind;version="[0,3)",javax.xml.bind.annotation;version="[0,
3)", ...
It will also impact the Karaf features, https://github.com/apache/cxf/blob/master/osgi/karaf/features/src/main/resources/features.xml, but we could fix that later.
Thank you.
Hi @jimma , @reta ,
Thanks for bringing up this discussion!
As my comment in the dev mailling list(Jakarta namespace and OSGI), I think this PR can skip OSGi support for now.
Best Regards Freeman
Hi @reta , @jimma ,
Surprisingly, I noticed that in the jakarta jar after transform, the OSGi headers by and large are also taken care by the eclipse transformer plugin(some magic must happen somewhere that we don't know).
For example, in the cxf-rt-frontend-jaxws-3.5.0-jakarta-SNAPSHOT.jar , the Import-Package part is {code} Import-Package: jakarta.activation;version="[2.0,3)",jakarta.annotatio n;version="[2.0,3)",javax.imageio,javax.imageio.stream,jakarta.jws;ve rsion="[0,3)",jakarta.jws.soap;version="[0,3)",jakarta.servlet;resolu tion:=optional;version="[5.0,6)",jakarta.servlet.http;resolution:=opt ional;version="[5.0,6)",javax.wsdl,javax.wsdl.extensions,javax.wsdl.e xtensions.http,javax.wsdl.extensions.soap,javax.wsdl.extensions.soap1 2,jakarta.xml.bind;version="[3.0,4)",jakarta.xml.bind.annotation;vers ion="[3.0,4)",jakarta.xml.bind.annotation.adapters;version="[3.0,4)", javax.xml.namespace,jakarta.xml.soap;version="[1.4,2)",javax.xml.stre am,javax.xml.transform,javax.xml.transform.dom,javax.xml.transform.sa x,javax.xml.transform.stream,javax.xml.validation,jakarta.xml.ws;vers ion="[0,3)",jakarta.xml.ws.handler;version="[0,3)",jakarta.xml.ws.han dler.soap;version="[0,3)",jakarta.xml.ws.http;version="[0,3)",jakarta .xml.ws.soap;version="[0,3)",jakarta.xml.ws.spi;version="[0,3)",jakar ta.xml.ws.spi.http;resolution:=optional;version="[0,3)",jakarta.xml.w s.wsaddressing;version="[0,3)",org.apache.aries.blueprint;resolution: =optional;version="[1.0,2)",org.apache.aries.blueprint.mutable;resolu tion:=optional;version="[1.0,2)",org.apache.cxf;version="[3.5,4)",org .apache.cxf.annotations;version="[3.5,4)",org.apache.cxf.attachment;v ersion="[3.5,4)",org.apache.cxf.binding;version="[3.5,4)",org.apache. cxf.binding.soap;version="[3.5,4)",org.apache.cxf.binding.soap.interc eptor;version="[3.5,4)",org.apache.cxf.binding.soap.model;version="[3 .5,4)",org.apache.cxf.binding.soap.saaj;version="[3.5,4)",org.apache. cxf.binding.soap.wsdl.extensions;version="[3.5,4)",org.apache.cxf.bin ding.xml;version="[3.5,4)",org.apache.cxf.bus.blueprint;version="[3.5 ,4)",org.apache.cxf.bus.spring;version="[3.5,4)",org.apache.cxf.commo n.classloader;version="[3.5,4)",org.apache.cxf.common.i18n;version="[ 3.5,4)",org.apache.cxf.common.injection;version="[3.5,4)",org.apache. ..... {code}
Please notice the jakarta. Import-Package. So I think this eclipse transformer plugin has been OSGi friendly already.
@jimma Just one minor issue I found with the GAV pattern after trasform. For exmaple, I have
/Users/ffang/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxws-3.5.0-jakarta/SNAPSHOT/cxf-rt-frontend-jaxws-3.5.0-jakarta-SNAPSHOT.jar
The jakarta classfier get inserted between 3.5.0 and SNAPSHOT, IMO, the expected path should be like
/Users/ffang/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxws/3.5.0-SNAPSHOT/cxf-rt-frontend-jaxws-3.5.0-SNAPSHOT-jakarta.jar
Could you please fix it?
Thanks! Freeman