module-info.java references legacy javax.ws.rs.api

[triceo]

I'm using 2.10.0-pr1 in a modular environment. In order to do that successfully, I have to have my module require com.fasterxml.jackson.jaxrs.json. Immediately after I do that, my application refuses to start due to module javax.ws.rs.api missing. This is not surprising, as my project is converted to use the new Jakarta APIs. And in those, the new module name is java.ws.rs.

However, this begs two questions:

• Is Jackson intentionally dependent on the legacy EE APIs?
• And if so, what is the proper artifact I should use to get this working properly? To the best of my knowledge, the old JAX-RS APIs are not modularized, so I'm not even sure where the javax.ws.rs.api module should be coming from.

At the very least, I think that this is a bug in release notes which mention modularization, but do not point the user to any sort of solution to this modularization problem.

[cowtowncoder]

@triceo I am not an expert of, or even user of (at this point) of module system, so attempts at module info addition are bit of "best effort". Any flaws are accidental and due to inexperience. :)
I think @GedMarc can help here however, being more of an expert in this domain.

But as to question: no, intent is not to rely on legacy EE APIs. All we need is JAX-RS API.

Since pr1 is a pre-release version and the explicit goal is to try to weed out these issues, with help of users. So thank you for reporting the issue & helping issue figure out how to resolve it.

[oobles]

Just found this issue while moving from 2.9.9 to 2.10.0 in a module based application.

Looking at the pom.xml it shows a dependency:

      <groupId>javax.ws.rs</groupId>
      <!-- 05-Apr-2014, tatu: JAX-RS 2.x has different artifact-id, "javax.ws.rs-api"
        -->
      <artifactId>javax.ws.rs-api</artifactId>
      <version>2.0.1</version>
      <scope>provided</scope>
    </dependency>

I think because this is an old version it gets an automatic module name 'javax.ws.rs.api'. Can I suggest updating this to 2.1.1 which has a module name of 'java.ws.rs' that is compatible with the jakarta version.

I don't think 2.10.0 will be able to be used with anything that is using the 'java.ws.rs' module name until this is resolved.

[triceo]

@oobles Spot on, thanks!
@cowtowncoder Any chance this change would be considered for the next release?

[cowtowncoder]

Yes, I can make the change as long as someone else can verify it (just because I still work mostly in Java 8 environment). Seems like reasonable update so I have no specific concerns.

@GedMarc WDYT?

[triceo]

@cowtowncoder If there's nightly builds somewhere, I can grab them and plug them into my modular application.

[GedMarc]

@triceo @cowtowncoder @oobles

Phew, thank goodness I came across this a while ago,
A few things to consider here - The names are not finalized, jakarta cannot put anything into the javax and java packages (from jdk12 they've actually locked quite a few more packages) so the automatic module name of java.ws.rs is going to go away eventually for the jakarta replacement

So this particular one (jax rs) will actually have 3 names. Of which only one will be "The Module" and not the reservation automatic module name (which does not support jlink)

1. The artifact reference above is incorrect. It should be (with scope provided)

     <dependency>
            <groupId>jakarta.ws.rs</groupId>
            <artifactId>jakarta.ws.rs-api</artifactId>
            <version>2.1.6</version>
        </dependency>

2. The module info file must specify all 3 module names as static, and allow the consumer to dictate which module will be referenced by using the "static" command.
   This means the consumer has to specify which module they are using and will have to include the module as required in your app module-info / requirement module info

The below module info declaration will enable backwards support and future support

//RS EE8
requires static jakarta.ws.rs-api;
//RS 2.0^
requires static java.ws.rs;
//RS 2.0 and Down
requires static javax.ws.rs.api;

If you are using a modular JAXB - you will need --add-opens java.ws.rs/javax.ws.rs.core=java.xml.bind as automatic module names are not modules and don't specify opens bla bla bla...

FYI
I'm done with the JAXB/Jakarta artifacts and will update that JRE 11 test projects once i manage to fix my central deploy... Then you can start building JLinks for all of these things as well
I'm really trying to get these tests in before the final 2.10 release but it's starting to look like i'm not going to make it

Current status - Only have antlr (for hibernate) left to do. Working closely with the apache guys to get the damn commons libraries pulled in and released.

[DEBUG]  module: cache.api automatic: false
[DEBUG]  module: cache.annotations.ri.guice automatic: false
[DEBUG]  module: cache.annotations.ri.common automatic: false
[DEBUG]  module: org.apache.commons.io automatic: false
[DEBUG]  module: org.hibernate.orm.jcache automatic: false
[DEBUG]  module: com.hazelcast.all automatic: false
[DEBUG]  module: org.json automatic: false
[DEBUG]  module: org.apache.poi automatic: false
[DEBUG]  module: org.apache.commons.logging automatic: false
[DEBUG]  module: org.apache.commons.codec automatic: false
[DEBUG]  module: org.apache.commons.math3 automatic: false
[DEBUG]  module: org.apache.commons.collections4 automatic: false
[DEBUG]  module: org.apache.poi.ooxml automatic: false
[DEBUG]  module: org.apache.commons.compress automatic: false
[DEBUG]  module: org.apache.xmlbeans automatic: false
[DEBUG]  module: com.microsoft.sqlserver.jdbc automatic: false
[DEBUG]  module: javassist automatic: false
[DEBUG]  module: org.jboss.logging automatic: false
[DEBUG]  module: java.json automatic: false
[DEBUG]  module: org.hibernate.orm.core automatic: false
[DEBUG]  module: java.persistence automatic: false
[DEBUG]  module: java.transaction automatic: false
[DEBUG]  module: org.hibernate.commons.annotations automatic: false
[DEBUG]  module: jandex automatic: false
[DEBUG]  module: com.fasterxml.classmate automatic: false
[DEBUG]  module: dom4j automatic: false
[DEBUG]  module: net.bytebuddy automatic: false
[DEBUG]  module: javax.security.jacc.api automatic: false
[DEBUG]  module: javax.servlet.api automatic: false
**[DEBUG]  module: antlr automatic: true**
[DEBUG]  module: java.xml.bind automatic: false
[DEBUG]  module: java.validation automatic: false
[DEBUG]  module: javax.inject automatic: false
[DEBUG]  module: org.apache.commons.text automatic: false
[DEBUG]  module: org.apache.commons.lang3 automatic: false
[DEBUG]  module: com.google.common automatic: false
[DEBUG]  module: java.annotation automatic: true
[DEBUG]  module: tm.bitronix.btm automatic: false
[DEBUG]  module: aopalliance automatic: false
[DEBUG]  module: com.google.guice.extensions.persist automatic: true
[DEBUG]  module: org.hibernate.validator automatic: false
[DEBUG]  module: javax.el automatic: false
[DEBUG]  module: com.google.guice automatic: false
[DEBUG]  module: io.github.classgraph automatic: false
[DEBUG]  module: com.fasterxml.jackson.databind automatic: false
[DEBUG]  module: com.fasterxml.jackson.annotation automatic: false
[DEBUG]  module: com.fasterxml.jackson.core automatic: false
[DEBUG]  module: com.fasterxml.jackson.module.guice automatic: false
[DEBUG]  module: com.fasterxml.jackson.datatype.jdk8 automatic: false
[DEBUG]  module: jakarta.activation automatic: false
[DEBUG]  module: java.activation automatic: false

If you want any of these artifacts or collections (source bla bla bla) just ask, yes I'm using these for the JRE 11 tests on jaxb, hibernate, rs, and the rest etc...

[GedMarc]

@triceo For nightly builds that run directly off a branch in github a great option is jitpack, You could reference e.g. the pull request by including the following in your build

https://jitpack.io/#GedMarc/jackson-jaxrs-providers/2.2-SNAPSHOT

<dependency>
	    <groupId>com.github.GedMarc</groupId>
	    <artifactId>jackson-jaxrs-providers</artifactId>
	    <version>2.10-SNAPSHOT</version>
	</dependency>

[cowtowncoder]

Quick note here: Jackson 2.10.0 was just released, so I can apply changes to 2.10.1 patch... which ideally would not break things that were working to some degree.
Whereas I plan for 2.11 to be released with much shorter cycle than 2.10 (which took almost 2 years since 2.9), possibly release candidate by end of 2019 and release in January.

So, with that, @GedMarc do you think change to static is safe here? I think that based on earlier discussions this is the way to go, in general, but want to know if tactically it makes sense.
Also, would there be pom.xml change to go with the patch?

[cowtowncoder]

Merged PR #116, and also updated compile dependency as suggested. Changes will affect 2.10.1.

[jonathanlocke]

@oobles You're a life-saver. I just spent about 4 hours trying to figure this out! Thanks.