Migrate to Jakarta EE 9

[tamersaadeh]

Jakarta EE 9 platform renames all the "old" namespaces from javax.* to jakarta.*. This pull request performs this migration so that when Jacakrta EE 9 is released in June 2020 it will be compatible.

I ran mvn test and travis builds with no failures*.

Note 1: this is completely incompatible with the old namespace, so probably the major version of the library should be bumped.
Note 2: currently depends on pre-released versions of the JAXB specification (RC3). This can be updated when the final version is released.
Note 3: this PR is similar to my PR for FasterXML/jackson-modules-base#95 and FasterXML/jackson-dataformat-xml#407

*: I needed to modify 3 tests (7ff95e7) but I'm not exactly sure way this change was needed on my development PC.

[GedMarc]

9.4.29.v20200521

[tamersaadeh]

Sure I can update this, I just didn't think my commits should touch other dependency not strictly relevant to the pull request.

[fenixcitizen]

I think this line and all similar in other module-info.java files should not change. See #127 and #121

[GedMarc]

the static clauses in the moditect file are for backwards compatibility,

don't change them, add new ones instead - this makes sure that when modules are used, it can be done easily

also jakarta artifacts should be a shade on the javax. ones, with the package replaced, it shouldn't be a source code change

[cowtowncoder]

Just a quick comment: I have no plans to move ahead with this change at this point in time.
I am not against migration in principle but it does not sound like this could be done without significant breakage for existing users, for now.

[joschi]

@tamersaadeh @cowtowncoder With the jakarta.* and javax.* namespaces existing in parallel, I think it would make sense to cater both ecosystems with jackson-jaxrs-providers because javax.* won't be vanishing over night.

What do you think?

[cowtowncoder]

@joschi Agreed, and for 2.12 there is something like that (see #127) -- "jakarta" classifier for new variants.

[joschi]

Agreed, and for 2.12 there is something like that (see #127) -- "jakarta" classifier for new variants.

As far as I understand #127 only addresses the JPMS module information but doesn't update the package imports in the actual source files, does it?

So we would need a second set of sources (src/main/jakarta?) with the appropriate imports from jakarta.*.

[GedMarc]

no - it get's shaded in with all the imports correctly applied

[joschi]

no - it get's shaded in with all the imports correctly applied

@GedMarc Could you elaborate? I've checked out the master branch of this repository and ran mvn install but there are no artifacts using the Jakarta EE namespace implemented by Jersey 3.0.0 (only the default jar and the no-metainf-services artifacts).

I also only see Jersey 2.25.1 referenced in the POM files, not Jersey 3.0.0 (as of fcc3e95):

jackson-jaxrs-providers/pom.xml

Line 37 in fcc3e95

<version.jersey>2.25.1</version.jersey>

[GedMarc]

No the code itself does not reference it,. it get's shaded in and all the relevant imports get modified into a classified artefact on pom, called "-jakarta",

Look at https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html

This keeps a single code base, while enabling full jakarta usage.
The implementation is correct and complete, I forgot about the OSGi things will see if this has been pulled in or if I must do it quick

You need to follow the readme and reference the jakarta classified artefacts.

[joschi]

No the code itself does not reference it,. it get's shaded in and all the relevant imports get modified into a classified artefact on pom, called "-jakarta",

Turns out that this is missing on the master branch and it's only available on the 2.12 branch.

[GedMarc]

:D

Ok i think it might be waiting for the latest merge,
Although you make a good point...

@cowtowncoder are you targeting javax. for 3.0 release? Should I update the references?

[cowtowncoder]

Ok, so the omission from master is an artifact of one pom.xml merge conflicts being ignored -- since that is a royal PITA when rolling forward changes after releasing new versions (since version numbers across branches will "conflict" when releases are made from maintenance branches).
Basically all changes to pom.xmls need to be manually merged.

As to 3.0 itself: I don't yet know, so probably the best thing to do would be to just merge functionality from 2.12, and figure it out in future, based on success of Jakarta variant.