Using `jackson-module-jakarta-xmlbind-annotations` 2.15.2 fails in OSGi Environment with JAXB 4
col-panic opened this issue · 10 comments
Using the bundle Jackson Module Jakarta Xmlbind Annotations » 2.15.2 by integrating it via the target like
fails with
-> Bundle-SymbolicName: org.glassfish.jersey.media.jersey-media-json-jackson; bundle-version="3.1.3"
org.glassfish.jersey.media.jersey-media-json-jackson [40]
Unresolved requirement: Import-Package: com.fasterxml.jackson.module.jaxb; version="[2.14.0,3.0.0)"; resolution:="optional"
Unresolved requirement: Import-Package: com.fasterxml.jackson.module.jakarta.xmlbind; version="[2.14.0,3.0.0)"
-> Export-Package: com.fasterxml.jackson.module.jakarta.xmlbind; bundle-symbolic-name="com.fasterxml.jackson.module.jackson-module-jakarta-xmlbind-annotations"; bundle-version="2.15.2"; version="2.15.2"; uses:="com.fasterxml.jackson.annotation,com.fasterxml.jackson.core,com.fasterxml.jackson.databind,com.fasterxml.jackson.databind.cfg,com.fasterxml.jackson.databind.introspect,com.fasterxml.jackson.databind.jsontype,com.fasterxml.jackson.databind.type,com.fasterxml.jackson.databind.util,jakarta.xml.bind.annotation,jakarta.xml.bind.annotation.adapters"
com.fasterxml.jackson.module.jackson-module-jakarta-xmlbind-annotations [86]
Unresolved requirement: Import-Package: jakarta.xml.bind; version="[3.0.0,4.0.0)"
I can see that the limitation is also set in the META-INF/MANIFEST.MF in
Import-Package: com.fasterxml.jackson.annotation;version="[2.15,3)",co
m.fasterxml.jackson.core;version="[2.15,3)",com.fasterxml.jackson.cor
e.util;version="[2.15,3)",com.fasterxml.jackson.databind;version="[2.
15,3)",com.fasterxml.jackson.databind.cfg;version="[2.15,3)",com.fast
erxml.jackson.databind.deser.std;version="[2.15,3)",com.fasterxml.jac
kson.databind.introspect;version="[2.15,3)",com.fasterxml.jackson.dat
abind.jsonFormatVisitors;version="[2.15,3)",com.fasterxml.jackson.dat
abind.jsontype;version="[2.15,3)",com.fasterxml.jackson.databind.json
type.impl;version="[2.15,3)",com.fasterxml.jackson.databind.node;vers
ion="[2.15,3)",com.fasterxml.jackson.databind.ser.std;version="[2.15,
3)",com.fasterxml.jackson.databind.type;version="[2.15,3)",com.faster
xml.jackson.databind.util;version="[2.15,3)",com.fasterxml.jackson.mo
dule.jakarta.xmlbind.deser;version="[2.15,3)",com.fasterxml.jackson.m
odule.jakarta.xmlbind.ser;version="[2.15,3)",jakarta.activation;versi
on="[2.0,3)",jakarta.xml.bind;version="[3.0,4)",jakarta.xml.bind.anno
tation;version="[3.0,4)",jakarta.xml.bind.annotation.adapters;version
="[3.0,4)",javax.activation;resolution:=optional
JAXB is brought in as a dependency by jersey-media-jackson
What version of jackson-module-jakarta-xmlbind-annotations am I supposed to use here? Is there already a version compatible with jakarta.xml.bind >= 4?
Unfortunately I do not know enough about OSGi resolution to know.
The whole transition from old JAXB annotations to Jakarta-binding is a royal shitshow, alas.
If anyone can resolve this and submit a patch, would be happy to merge.
@GedMarc any thoughts? (aside from "OSGi sucks" :) )
I don' know, where the MANIFEST.MF is generated (I think it must be during the process of deploying the artifact to maven), but generally, is there a reason to limit Import-Package: jakarta.xml.bind; version="[3.0.0,4.0.0)" and subpackages to "[3.0.0,4.0.0)"? If not, a simple change to "[3.0.0,5.0.0)" to also include version 4 (as defined for Java EE 10 https://jakarta.ee/specifications/xml-binding/4.0/ ) might already suffice. This patch should be rather trivial!
MANIFEST.MF is generated by Maven (OSGi) bundle plugin, based on pom.xml and possible overrides. Dependency from FasterXML/oss-parent project's parent pom (https://github.com/FasterXML/oss-parent/blob/master/pom.xml#L248 ) is:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
But I am not 100% sure where logic for version range generation resides -- definitions are not included in pom.xml, nor do we use version ranges for Maven dependencies (since they don't really work well with tooling).
So it is unfortunately not just matter of changing explicit Import-Package directive as those are generated by the plug-in (AFAIK).
I think it might be defined in here _versionpolicy but I'm struggling
to find the documentation to this property, which is currently set to
<osgi.versionpolicy>${range;[===,=+);${@}}</osgi.versionpolicy>
A wild guess would be to change this to
<osgi.versionpolicy>${range;[===,=+];${@}}</osgi.versionpolicy> then it should at least work with the 4.0.0 version.
But in https://mvnrepository.com/artifact/com.fasterxml.jackson.module/jackson-module-jakarta-xmlbind-annotations/2.15.2 it is even mentioned to accept jakarta.xml.bind » jakarta.xml.bind-api 4.0.1 so we should give this a more educated approach!
Will try to make a meaning of this property!
Seems like a good link https://bnd.bndtools.org/macros/range.html
But I am not 100% sure where logic for version range generation resides -- definitions are not included in
pom.xml, nor do we use version ranges for Maven dependencies (since they don't really work well with tooling).
Does this mean that you actively disable the _versionpolicy property on build, s.t. its not to be considered?
I was only talking about Maven side of things: that is, we would never use version ranges for Maven dependencies.
I did not mean it would not be used for OSGi.
Unfortunately I do not know much about workings of Maven bundle (felix?) plugin, or _versionpolicy to be sure.
But. I think at first it would make sense to try overriding that settings on Jakarta XMLBind Annotations module only, not in parent pom (I think it is defined in a way to be overridable), and if that works, publish as part of 2.16.0-rc1 that I plan on publishing some time this week.
If you could help with this @col-panic that'd be awesome.
@cowtowncoder this should do the trick. I've seen this a few times in the Eclipse related plugins,
where they enable a certain range for patch levels to apply. So this should cover all jakarta.xml.bind until 4.0.99,
but still leave it closed for a major version like 4.1 - where API might break.
Thank you @col-panic for providing the fix!