Jakarta Namespace Support

[GedMarc]

The purpose of this PR is to enable compatibility with the Jakarta artifacts being released

All artifacts are available at https://jakarta.oss.sonatype.org/content/groups/staging as finals and are slowly being pushed to maven central.

This places the module info file into the META-INF/versions/11 directory, as well as creates a shaded artifact with the classifier of "jakarta", with the namespace changed.

This allows usage for Jakarta XML Bind version 3.0.0

This PR solves for FasterXML/jackson-jaxrs-providers#124

<groupId>
<artifactId>
<classifier>jakarta</classifier>
<version>2.12

@cowtowncoder @tamersaadeh

Please review and comment as necessary

[GedMarc]

this solves the javassist and jaxen issues in older jdk 7 frameworks reading module-info files, as well as doesn't get removed during the shade for jakarta namespacing

this was the trick to make it all work

[cowtowncoder]

Do we care about JDKs 9 and 10? They are not LTS versions but just in case...

[GedMarc]

There is always that one person so it definitely is safer -

I double checked - for me I put it there as other modules override at 11, and i needed to overwrite those xD So no issue there will update

[cowtowncoder]

I don't quite understand -- what exactly is being shaded in and why?

[GedMarc]

:)

Jakarta XML Binding has placed everything into jakarta. namespace, and I've hit a roadblock on the jaxb, and jaxrs modules in moving modular to Jakarta 9, whose release should be completely in central by the end of the coming week.

javax.xml.bind is now jakarta.xml.bind (although the module is still named java.xml.bind) and javax.ws.rs is jakarta.ws.rs -

Going through that rather lengthy discussion on the mentioned issue, it became apparent that there had to be a way to do it with no code change -

This is what I found that works with zero changes :- shade into a classified artifact, and if need be override the module-info with a custom one for jakarta specifically :)

this is also my solution for references to javax.activation (to jakarta.activation in namespace not just modules)

This lets people consume the modules affected with only adding a <classifier> to their dependency and not breaking anything else :)

[GedMarc]

[GedMarc]

Generated Artifacts :

jackson-module-jaxb-annotations-2.12.0-rc2-SNAPSHOT.zip
jackson-module-jaxb-annotations-2.12.0-rc2-SNAPSHOT-jakarta.zip

[GedMarc]

These are the locations that this PR resolves for

<jakarta.xml.jaxb.api.version>3.0.0</jakarta.xml.jaxb.api.version>

 <dependency>
                <groupId>jakarta.xml.bind</groupId>
                <artifactId>jakarta.xml.bind-api</artifactId>
                <version>${jakarta.xml.jaxb.api.version}</version>
                <optional>true</optional>
            </dependency>

            <dependency>
                <groupId>org.glassfish.jaxb</groupId>
                <artifactId>jaxb-runtime</artifactId>
                <version>${jakarta.xml.jaxb.api.version}</version>
                <optional>true</optional>
            </dependency>


            <dependency>
                <groupId>com.sun.xml.bind</groupId>
                <artifactId>jaxb-impl</artifactId>
                <version>${jakarta.xml.jaxb.api.version}</version>
                <optional>true</optional>
            </dependency>



<repositories>
                <repository>
                    <id>Jakarta</id>
                    <url>https://jakarta.oss.sonatype.org/content/groups/staging/</url>
                </repository>
            </repositories>

[cowtowncoder]

Ok, so does this create additional second jar, with different classifier, in addition to "vanilla" one?
So that the default one already produced is not very different (except for modules-info class being under jdk-version-dependant dir); but there's second jar with additional embedded classes from javax.activation?

But even then, from what I remember wrt OSGi, there is always backlash on adding shaded secondary components, when they overlap with other artifacts (that is, classes also provided by a standalone package).

[cowtowncoder]

Ok n/m. Cloned branch, looked at what is produced. So it is not shading in activation jar classes or anything so that's fine. I assume it renames references somewhere... in modules-info.class or... ?

[GedMarc]

The relocation on the shade is doing a transform on the .class files just renaming javax. to jakarta. :)

There shouldn't be any clash with OSGi - the bundle plugin looks to do quite a good job, but no files other than meta-inf/services and .class files are altered during the shade :)