jakarta.activation version conflict in 2.13

Question

jakarta.activation version conflict in 2.13

mkpaz opened this issue 3 years ago · 14 comments

I've tried to upgrade to 2.13 branch just recently to get rid of old jaxb namespaces (#116). However after I've tried to build my app with jlink I've got this:

Error: Two versions of module jakarta.activation found in ..\target\modules (jakarta.activation-api-1.2.1.jar and jakarta.activation-2.0.1.jar)

I'm using new Jakarta XML Bind module, here is dependency tree fragment:

[INFO] |  +- com.fasterxml.jackson.core:jackson-databind:jar:2.13.0:compile
[INFO] |  |  +- com.fasterxml.jackson.core:jackson-annotations:jar:2.13.0:compile
[INFO] |  |  \- com.fasterxml.jackson.core:jackson-core:jar:2.13.0:compile
[INFO] |  +- com.fasterxml.jackson.dataformat:jackson-dataformat-properties:jar:2.13.0:compile
[INFO] |  +- com.fasterxml.jackson.dataformat:jackson-dataformat-xml:jar:2.13.0:compile
[INFO] |  |  +- org.codehaus.woodstox:stax2-api:jar:4.2.1:compile
[INFO] |  |  \- com.fasterxml.woodstox:woodstox-core:jar:6.2.6:compile
[INFO] |  +- com.fasterxml.jackson.module:jackson-module-jakarta-xmlbind-annotations:jar:2.13.0: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:1.2.1:compile
[INFO] |  +- com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:jar:2.13.0:compile
[INFO] |  |  \- org.yaml:snakeyaml:jar:1.28:compile

So, jakarta.activation-api:jar:1.2.1 (Jackson dependency) conflicts with jakarta.activation:jar:2.0.1 (Jakarta XML Bind transitive dependency), because they're both using same module name.

To fix this you probably should either exclude jakarta.activation-api from module dependencies or switch to the 4.x branch that doesn't depend on old activation API. Links to compare:

3.x
4.x

A simple workaround is to include Bind API 4.x branch as a direct dependency, it's on RC stage.

Answer 1 · 2021-10-01T21:19:01.000Z

Sigh. I wish there was someone to test this with 2.13.0-rc1 or rc2 (not mean as complaint to you @mkpaz -- thank you for reporting this :) ).

I think I need some help here: one nice thing would be a test reproduction (maybe for jackson-integration-tests).
And second of course specific change & verification.

My usual go to dev is @GedMarc -- WDYT? :)

Answer 2 · 2021-12-08T03:55:01.000Z

Hi @GedMarc -- any concerns, comments, on possibly doing this for 2.13.1 / 2.14.0?

Answer 3 · 2022-01-16T00:35:34.000Z

Hi @GedMarc: this seems like something to do, but would appreciate an opinion

@mkpaz So, would #166 be what you are thinking? If you could verify that this would resolve your issue, I think I could merge it for inclusion in 2.13.2.

Answer 4 · 2022-01-26T03:50:17.000Z

Hi @mkpaz! Sorry to pester you but I was hoping to merge this, but wanted to first verify that #166 would resolve the issue -- if you have an easy way to verify. From simple "mvn dependency:tree" it would seem to be the way to go, but I don't have build for actual module usage.

Answer 5 · 2022-01-26T08:19:04.000Z

ok we have a few updates on the jakarta suite on Monday -
activation should bump up, i'm busy testing the change site in production (yes sigh), we'll know if anything goes awry by the end of the day,
JAXB for jakarta also got updated this week, so I'm gonna run through those in our UAT

Answer 6 · 2022-01-26T08:20:21.000Z

@mkpaz do you have a means of managing dependency versions? in poms you could manage the jakarta activation version from your pom file (which is how i'm testing) and ensure it uses the right one

Answer 7 · 2022-01-26T08:58:07.000Z

Sorry for the late response and thanks for the fix. This would work since you basically just switching to older activation-api version and it's the same version jaxb-api uses as its dependency. But I'm not sure how should I test this as it's not yet merged and not released. Do I need to build Jackson locally with this fix? For my project I just bumped jaxb-api version and have no complaints.

Answer 8 · 2022-01-26T09:11:14.000Z

In your pom file there is a section called <dependencyManagement> which you can use to fix versions across all dependencies,
Check the documentation https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#:~:text=Dependency%20Management%20The%20dependency%20management%20section%20is%20a,references%20to%20the%20artifacts%20in%20the%20child%20POMs.

Answer 9 · 2022-01-26T09:46:37.000Z

If you mean this, yes, it works:

<dependencyManagement>
    ...
    <dependency>
        <groupId>com.fasterxml.jackson.module</groupId>
        <artifactId>jackson-module-jakarta-xmlbind-annotations</artifactId>
        <version>2.13.1</version>
        <exclusions>
            <exclusion>
                <groupId>jakarta.activation</groupId>
                <artifactId>jakarta.activation-api</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
    <dependency>
        <groupId>com.sun.activation</groupId>
        <artifactId>jakarta.activation</artifactId>
        <version>2.0.1</version>
    </dependency>
    ...
</dependencyManagement>

Answer 10 · 2022-01-27T01:32:27.000Z

Ok, I'll go ahead and get this merged then. Thank you @mkpaz @GedMarc !

Answer 11 · 2022-01-27T01:49:04.000Z

@mkpaz You would be using 2.13.2-SNAPSHOT versions to check the fix, after building. I'll push a snapshot now since change is merged.

Answer 12 · 2022-03-07T06:45:57.000Z

Please note that jakarta activation 2.0 moves fully the namespace to package jakarta.* - at the java source-code and runtime-level, unlike 1.2 (which is backward-compatible - even if the artifact name is jakarta.* at the POM level, at source level it stays in javax.*).

~~This is a huge move. I don't think this should happen until a full release (2.14? 3.X?), definitely not in a minor hotfix as it will break compatibility everywhere.~~

~~As an example, Spring Framework won't make the move to jakarta.*-upgraded Jakarta EE releases until Spring 6.0 - all of Spring 5.3 maintenance releases stay in javax.*-package dependencies.~~

(please disregard my comment as I see this project already depends on jakarta XML 3.x in this module. I assumed it was staying in javax, as I use it heavily and still relying on javax.* for everything including spring 5.3... my bad)

Answer 13 · 2022-03-08T00:49:19.000Z

@flozano No problem: actually we have separate module for new "jakarta" annotations; old "JAXB annotations" will not be upgraded and will retain old dependency. This because like you say it is a major incompatibility, fork point.

So the idea is that only new jakarta-xmlbind will move to use Jakarta dependency. This was added in 2.13.

Answer 14 · 2022-03-08T00:49:40.000Z

This was released in 2.13.2, out now.