ehcache 3.9.1 strange jaxb-runtime version dependency / compile error

[qeepcologne]

after upgrade 3.9.0 -> 3.9.1 i get strange compile error:

Failed to collect dependencies at org.ehcache:ehcache:jar:3.9.1 -> org.glassfish.jaxb:jaxb-runtime:jar:2.3.0-b170127.1453 -> org.glassfish.jaxb:jaxb-core:jar:2.3.0-b170127.1453 -> javax.xml.bind:jaxb-api:jar:2.3.0-b161121.1438: Failed to read artifact descriptor for javax.xml.bind:jaxb-api:jar:2.3.0-b161121.1438: Could not transfer artifact javax.xml.bind:jaxb-api:pom:2.3.0-b161121.1438 from/to releases.java.net (http://maven.java.net/content/repositories/releases/): Transfer failed for http://maven.java.net/content/repositories/releases/javax/xml/bind/jaxb-api/2.3.0-b161121.1438/jaxb-api-2.3.0-b161121.1438.pom: PKIX path validation failed: java.security.cert.CertPathValidatorException: validity check failed: NotAfter: Fri Feb 19 13:00:00 CET 2021

[chrisdennis]

In 3.9.1 the jaxb-runtime dependency changed from a specific org.glassfish.jaxb:jaxb-runtime:2.3.1 to the version range org.glassfish.jaxb:jaxb-runtime:[2.2,3). This means rather than terminating it's search upon finding 2.3.1 your build system will now search all configured repositories to find the latest available version that satisfies the range. This means it's now looking at your configured maven.java.net repository and it appears the SSL setup there is broken: https://www.ssllabs.com/ssltest/analyze.html?d=maven.java.net

[qeepcologne]

that's true, but first i never used maven.java.net (i also grep -r "maven.java.net" in the whole project without result) and second why is that really old beta version choosed?

[chrisdennis]

I don't think it's necessarily choosing that version. I think it's simply pulling the pom for that version as part of dependency resolution. Regarding why it's accessing maven.java.net, assuming this is a maven build system I would check the effective-pom: mvn help:effective-pom and see if you have anything in your ~./.m2/settings.xml that could be causing that.

[qeepcologne]

Thanks for the help, i couldn't find anything about jaxb or java.net in that output too,
i mean i could always fix that via explicit version and/or excludes, just trying to understand.
The compile problem is gone, they fixed their ssl certificate.
And also that missing package is not added to the shaded jar, but too many different
jaxb variants via jackson, hibernate, restassured and ehcache (jaxb-api-2.3.1, jaxb-core-3.0.0-M5/jax-runtime-3.0.0M5,
jax-impl-2.3.3, and also jakarta.xml.bind-api-2.3.2).

[chrisdennis]

If you're running on Java 8 (or on Java 9 and want to add the internal jaxb to the module path) then you can exclude the jaxb-runtime dependency. This is only here to avoid failures on Java 11 environments.

[dave-kennedy]

If you're running on Java 8 (or on Java 9 and want to add the internal jaxb to the module path) then you can exclude the jaxb-runtime dependency. This is only here to avoid failures on Java 11 environments.

Like so?

    <dependency>
      <groupId>org.ehcache</groupId>
      <artifactId>ehcache</artifactId>
      <exclusions>
        <exclusion>
          <groupId>org.glassfish.jaxb</groupId>
          <artifactId>jaxb-runtime</artifactId>
        </exclusion>
      </exclusions>
    </dependency>

[chrisdennis]

Yes, that should work.

[scholzb-hb]

We have a similar issue with Ehcache 3.10.2:

Failed to collect dependencies at org.ehcache:ehcache:jar:3.10.2 -> org.glassfish.jaxb:jaxb-runtime:jar:2.3.0-b170127.1453 -> org.glassfish.jaxb:jaxb-core:jar:2.3.0-b170127.1453 -> javax.xml.bind:jaxb-api:jar:2.3.0-b161121.1438: Failed to read artifact descriptor for javax.xml.bind:jaxb-api:jar:2.3.0-b161121.1438: Could not transfer artifact javax.xml.bind:jaxb-api:pom:2.3.0-b161121.1438 from/to netbeans (http://bits.netbeans.org/nexus/content/groups/netbeans): Not authorized -> [Help 1]

We have analysed the root cause:

The effect that the Maven build is accessing repositories like http://maven.java.net or http://bits.netbeans.org/nexus/content/groups/netbeans is not caused by the local Maven configuration. In fact the parent POM of org.glassfish.jaxb:jaxb-runtime defines those repositories, for example see https://repo1.maven.org/maven2/com/sun/xml/bind/mvn/jaxb-parent/2.3.0/jaxb-parent-2.3.0.pom. This has been removed in a later version, but is still present in the old beta version 2.3.0-b170127.1453 which is now being checked.

@chrisdennis, you may be right that this old beta version will not actually be "chosen" in the end, but since it is defining some invalid repositories, the version range processing fails at this point.

A workaround which is also valid for Java 17 is to define an explicit version for org.glassfish.jaxb:jaxb-runtime.

Wouldn't it be a good idea to at least restrict the version range so that only versions without repository definitions are included?

[davsclaus]

doing this in a patch release is really really bad - this should have only been done in 3.10 release!

[Jan-Thes]

This or a very similar error still happens for us, we are relying on the latest version of CXF security that still supports the javax namespace instead of the jakarte namespace, specifically CXF 3.6.x (they all use ehcache 3.10.8):

(no settings.xml was used, and mvn dependency:tree fails with this error):

Failed to collect dependencies at org.apache.cxf:cxf-rt-ws-security:jar:3.6.1
  -> org.ehcache:ehcache:jar:3.10.8
    -> org.glassfish.jaxb:jaxb-runtime:jar:2.3.0-b170127.1453
      -> org.glassfish.jaxb:jaxb-core:jar:2.3.0-b170127.1453
        -> javax.xml.bind:jaxb-api:jar:2.3.0-b161121.1438:
        Failed to read artifact descriptor for javax.xml.bind:jaxb-api:jar:2.3.0-b161121.1438:
        The following artifacts could not be resolved: javax.xml.bind:jaxb-api:pom:2.3.0-b161121.1438 (absent):
        Could not transfer artifact javax.xml.bind:jaxb-api:pom:2.3.0-b161121.1438 from/to maven-default-http-blocker (http://0.0.0.0/):
        Blocked mirror for repositories: [releases.java.net (http://maven.java.net/content/repositories/releases/, default, releases+snapshots), shapshots.java.net (http://maven.java.net/content/repositories/snapshots/, default, releases+snapshots), jvnet-nexus-staging (http://maven.java.net/content/repositories/staging/, default, releases+snapshots), netbeans (http://bits.netbeans.org/nexus/content/groups/netbeans, default, releases)]

Since CXF pulls in a different version of the jaxb-runtime (cxf-core directly requires jaxb-runtime 2.3.8) anyway, i think that it can be safely excluded in CXF security if there exist other CXF dependencies in the POM, like shown by previous commenters:

<dependency>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-rt-frontend-jaxws</artifactId>
    <version>${version.cxf}</version>
</dependency>
<dependency>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-rt-ws-security</artifactId>
    <version>${version.cxf}</version>
    <exclusions>
        <exclusion>
            <groupId>org.glassfish.jaxb</groupId>
            <artifactId>jaxb-runtime</artifactId>
        </exclusion>
    </exclusions>
</dependency>