jakarta.activation module duplicate in transitive dependencies since 2.13.4

[agavrilov76]

Since version 2.13.4 jackson-jakarta-rs-providers transitively depends on jakarta.activation:jakarta.activation-api which provides thejakarta.activation Java module also provided by the com.sun.activation:jakarta.activation dependency:

> mvn dependency:tree
...
[INFO] \- com.fasterxml.jackson.jakarta.rs:jackson-jakarta-rs-json-provider:jar:2.13.4:compile
[INFO]    +- com.fasterxml.jackson.jakarta.rs:jackson-jakarta-rs-base:jar:2.13.4:compile
[INFO]    |  +- com.fasterxml.jackson.core:jackson-core:jar:2.13.4:compile
[INFO]    |  \- com.fasterxml.jackson.core:jackson-databind:jar:2.13.4:compile
[INFO]    \- com.fasterxml.jackson.module:jackson-module-jakarta-xmlbind-annotations:jar:2.13.4:compile
[INFO]       +- com.fasterxml.jackson.core:jackson-annotations:jar:2.13.4:compile
[INFO]       +- jakarta.xml.bind:jakarta.xml.bind-api:jar:3.0.1:compile
[INFO]       |  \- com.sun.activation:jakarta.activation:jar:2.0.1:compile
[INFO]       \- jakarta.activation:jakarta.activation-api:jar:2.1.0:compile

When running with Java Module modules the Java runtime fails if the module path contains duplicates.

A workaround for this issue is to explicitly exclude jakarta.activation:jakarta.activation-api.

Related issue: https://github.com/FasterXML/jackson-modules-base/issues/152

[cowtowncoder]

Jakarta/JAX-RS mess has proven to be a humongous.... gift... that keeps on giving. :-(

@agavrilov76 I may be misunderstanding things but it sounds like Maven dependencies are such that somehow non-Jakarta API is included but one that conflicts with Module definitions of Jakarta activation API. Is that correct? If so it sounds like we should add some sort of exclusion somewhere... but what, where? I guess the "jackson-modules-base" issue linked-to above could help (it was merge for 2.13.2).

/cc @GedMarc maybe you understand the issue better here and can suggest a fix? :)

[GedMarc]

There's a few things here that I can see -

i'll bump up https://github.com/FasterXML/jackson-jdk11-compat-test to the version in question to make sure, but this looks to be the activation module split between 2.0 and 2.1 - caused during the jakarta move of JAXB, the version here being used is 3.0.1 which is the midway release between javax and jakarta -

As far as I remember we use activation 2.1 from the final Jakarta release (v4), activation 2.0 is transiently included through the jaxb implementation 3.0.1 looking at the dep graphs, but is still the javax one just renamed to jakarta.

Workaround for now would be to either exclude activation 2.1 from RS, or 2.0 from Jaxb 3 (javax activation on jakarta jaxb release), or you could also bump JAXB to an official Jakarta release instead of intermediary v3 You could do this via a dependencyManagement article to fix the version to both libraries use the same to only sort out activation api

We could from our end, update the jakarta-xmlbind-annotations module to make the dependency of activation optional, or use a pass-through to reference to be able to use both modules optionally on a module layer?

The root module affected is the jakarta-xmlbind-annotations, I'll focus on that and see if we can get it backwards compatible as well, but for the RS module itself, I don't feel any changes are necessary

------ Cliff Notes Bad dependency version control on source project allows multiple versions of the same library in the classpath. Recommend that you use dependency management and fix the version descrepenacy

XMLBind-Annotations is on the correct activations-api for Jakarta releases, version 4, and shouldn't be modified, the source project references an intermediary release of jaxb, bringing in the faulted dependency

Dependency at fault - com.sun.activation:jakarta.activation:jar:2.0.1:compile Dependency should be - jakarta.activation:jakarta.activation-api

com.sun.activation is no longer a package of the JAXB suite, https://mvnrepository.com/artifact/com.sun.xml.bind/jaxb-impl/4.0.0 and shouldn't be referenced when using Jakarta artifacts

[GedMarc]

No issue - Just bad link of dependencies on the source project -

For reference please use the correct artifacts when writing jakarta projects -

[cowtowncoder]

Ok. If there are changes needed on Jackson components, however, the focus would be on 2.14.0 release. I don't know if or when 2.13.5 would be released.

I am not interested in modular use of JAXB-or-Jakarta, in that Jackson has forked packages already (JAX-RS / Jakarta-RS; JAXB / Jakarta-XmlBind (annotations)). But if there are cases where dependencies are wrong (Jakarta-variant somehow refers to pre-Jakarta deps) those should be removed if possible.

But sounds like perhaps no changes on Jackson side are needed?

[GedMarc]

Should we not update the dependency on the jaxb library to exclude the com.sun and include the jakarta. reference?

[cowtowncoder]

I don't think we have such a dependency? I did notice one test scoped dependency via RESTeasy that does reference to Jackson JAX-RS provider, however, which would be nice to eliminate. But just need a JAX-RS implementation for use by tests (which are granted kinda poor tests anyway, more smoke testing).

[cowtowncoder]

Ok, looking at this again, it does look like dependency sneaks in via 3.0.1 of Jakarta.xml.bind-api (through Jackson's matching module):

[INFO] +- com.fasterxml.jackson.module:jackson-module-jakarta-xmlbind-annotations:jar:2.18.0-SNAPSHOT:compile
[INFO] |  +- com.fasterxml.jackson.core:jackson-annotations:jar:2.18.0-SNAPSHOT:compile
[INFO] |  +- jakarta.xml.bind:jakarta.xml.bind-api:jar:3.0.1:compile
[INFO] |  |  \- com.sun.activation:jakarta.activation:jar:2.0.1:compile
[INFO] |  \- jakarta.activation:jakarta.activation-api:jar:2.1.0:compile

and possible solution would be to do this:

https://github.com/FasterXML/jackson-modules-base/issues/240

for Jackson 2.18.

@agavrilov76 WDYT?

[cowtowncoder]

Alas, that issue cannot be solved it seems -- next major version of Jakarta XML bind requires Java 11 and we have to support Java 8. Sigh.