2.10 - JAXB to JPMS

[GedMarc]

FasterXML/jackson-databind#2312

Need to remove the imports for packageversion (how on earth do you do that xD)

[cowtowncoder]

Ah, no, that would bring wrong PackageVersion -- probably brought in by IDE accidental. This is auto-generated from template as part of build process.

[cowtowncoder]

@GedMarc Thanks! Since there is already Moditect use in place I tried to figure out meaningful diff(s) and it looks like the key is that default Activation dependency should be excluded and another one added -- I am guessing since latter has module-info, former doesn't?

But I wasn't sure of Moditect settings additions: are those needed? Or was is just from earlier PR that added moditect usage bit different way? If you have time, have a look at 2.10 to see if things make sense. I am working on finalizing FasterXML/jackson-databind#2195 to get 2.10.0.pr1 out as soon as possible, but module info inclusion is the other big thing I want in there.

[GedMarc]

JAXB now uses jakarta (org.glassfish.jaxb and jakarta.jaxb.api-impl) and is JLink friendly (module-info's exist)

Update JAXB and Activation references to use the following for API

 <dependency>
            <groupId>jakarta.activation</groupId>
            <artifactId>jakarta.activation-api</artifactId>
 <version>1.2.1</version>
            <type>jar</type>
        </dependency>

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

Include for tests :

            <dependency>
                <groupId>org.glassfish.jaxb</groupId>
                <artifactId>jaxb-runtime</artifactId>
                <version>2.3.2</version>
            </dependency>

[cowtowncoder]

Added as suggested for 2.10, master (3.0). Removed provided scopes.

I suspect same changes then needed for JAX-RS provider repo?

[cowtowncoder]

@GedMarc At this point I think I am done (... right :) ) with most components (*) except for JAX-RS providers which may still have issues. I have hit some roadblocks wrt trying to verify goodness/lack thereof (see https://github.com/FasterXML/jackson-jdk11-compat-test for my feeble attempts), so could use help on sanity checking.

(*) not including Scala and Kotlin modules.

[GedMarc]

Right - so after all the comments and build checks - It's looking really fantastic! :)
Short of not including all the dependencies for the modules - each of them looks to be building great.

JaxRS - I've been part of the RestEasy team doing the JPMS updates as well, RestEasy 4 is fully compliant -
Ref : https://issues.jboss.org/browse/RESTEASY-2110 and https://issues.jboss.org/browse/RESTEASY-1533

Using the named libraries (jaxb/rest/jackson) here - https://github.com/GedMarc/GuicedRestServices/blob/master/pom.xml

I've linked it up with my modules for jackson, I can put together the test for you and follow up with the jboss guys on the migration to 3.0-snapshot once guice is done :)
(Being the only injection module even remotely close to compliance)

For Apache commons (all the dependencies that rely on it), I have been working with @jfallows (Here GedMarc/JPMSPendingParent#1) and it looks like those are all moving really quickly as well, to solve those dependencies for the likes of RestEasy, Guice, IO handlers, and the rest of that sort.

Personal opinion is obviously that Spring is going to suffer the most with blocked class handling, i know that @larsgrefer (from https://gitter.im/classgraph/Lobby) has been implementing the scanner from ClassGraph to load and do all that but i'm not sure that's going to get around the fat-jar and standard packaging restrictions for JPMS, including resource fetching from external modules (completely blocked now without an opens clause) - i have very strong doubts it's going to come through soon
Perhaps tagging him in here will notify him to update his spring libraries as well to 3.0.0 -

Java EE ends with Java 8, Jakarta 10 is marked for JPMS, but is over 2 years away- MicroProfile have no intention (even in v3) of moving to JPMS yet (even though its a rest container?) which I confirmed in a meetup last week.

I don't feel much time needs to be spent on these modules until the owners have updated their projects, these ones in particular have lots of work needed on that front, and some with large architectural changes.
For now the Jakarta movement of javax. namespace is going incredibly quickly, most modules have the strict naming it in tact using some other method i've never seen before

[cowtowncoder]

Ok thanks.

I think I will try to get 2.10.0.pr1 out as soon as practical (should happen before June 19th anyway, as I'll be going for 2 week vacation :) ), so if any special improvements make sense just let me know.
I guess I am ok with Guice module being delayed, and although ideally Woodstox would be great to solve (if shading could work), it's not a requirement.

[cowtowncoder]

I'll close this one, can start new for further changes (now that baseline exists).