Drop dependencies that pull in the defunct maven.java.net repositories

[vharseko]

Every build warns:

[WARNING] Could not transfer metadata /.meta/prefixes.txt from/to jvnet-nexus-releases (https://maven.java.net/content/repositories/releases/): (certificate_expired) PKIX path validation failed
[WARNING] Could not transfer metadata /.meta/prefixes.txt from/to jvnet-nexus-snapshots (https://maven.java.net/content/repositories/snapshots): (certificate_expired) PKIX path validation failed

Maven asks every remote repository it meets for /.meta/prefixes.txt, including the repositories declared in the POMs of dependencies and plugins. The jvnet-nexus-* repositories come from net.java:jvnet-parent; java.net was shut down and the certificate of maven.java.net has expired. The build itself is not affected, all artifacts come from Central. Three dependency paths make Maven query maven.java.net; this PR removes all three.

JAXB

javax.xml.bind:jaxb-api:2.3.1 (via jaxb-api-parent) and com.sun.xml.bind:jaxb-core:2.3.0.1 (via jaxb-bom:2.3.0.1) inherit jvnet-parent:5, which declares jvnet-nexus-releases. jaxb-api also brings javax.activation:javax.activation-api:1.2.0, whose parent com.sun.activation:all:1.2.0 inherits jvnet-parent:1 and its jvnet-nexus-snapshots. json-web-token and api-descriptor depended on them, together with jaxb-impl, and passed them on to every module that uses them, json-resource among them.

Both modules only used javax.xml.bind.DatatypeConverter, so they no longer depend on JAXB at all:

• SupportedEllipticCurve decodes the hex seeds of the curves itself instead of parseHexBinary.
• CrestStringSchema validates the date-time and date/full-date formats with javax.xml.datatype.DatatypeFactory from the JDK, which is what DatatypeConverterImpl called: parseDateTime is newXMLGregorianCalendar(...).toGregorianCalendar() after trimming XML white space, parseDate is the same without trimming. Run side by side over 32 inputs (valid and invalid values, surrounding white space, \u000b,  , years beyond 9999, 24:00:00), the old and the new code give the same result for each. The new CrestStringSchemaTest pins 24 of them and passes both before and after the change.
• The tests of json-web-token replace parseHexBinary and printHexBinary the same way.

The OSGi bundles of both modules no longer import javax.xml.bind; api-descriptor imports javax.xml.datatype from the JRE instead.

framework-functional-tests got javax.xml.bind only through api-descriptor, and rest-assured 2.x loads it when it starts. It now declares jakarta.xml.bind-api:2.3.3, the same javax.xml.bind API with org.eclipse.ee4j:project as its parent, in test scope.

The root POM still manages jaxb-api, jaxb-core and jaxb-impl: OpenDJ opendj-core and OpenAM openam-core and openam-xacml3-schema declare them without a version and get it from this POM as a BOM. No module of this build depends on them, and the new ban-jvnet-parent enforcer rule fails the build if jaxb-api, jaxb-core or javax.activation-api come back.

rmic in persistit/core

The plugin dependency org.glassfish.corba:rmic:4.2.0-b007 and the CORBA, PFL and Gmbal artifacts it brings inherit jvnet-parent:5. It is updated to 4.2.5, whose tree has no java.net parent. The explicit org.ow2.asm:asm:7.3.1 is removed: rmic:4.2.5 depends on asm 9.1, and the pin would downgrade it.

This step generates nothing either before or after the change, although it logs Compiling 1 remote classes. The plugin swallows the compiler error and the build passes:

• on master, rmic fails with ASM8_EXPERIMENTAL can only be used by classes compiled with --enable-preview (the old rmic does not work with asm 7.3.1);
• with 4.2.5 on JDK 27, it fails with Unsupported class file major version 71 (asm 9.1 cannot read the JDK 27 classes);
• with 4.2.5 on JDK 11, it completes without errors but writes no _Stub class either.

So the content of the jar does not change. Whether the step is needed at all is left for a separate change.

org.json

org.json:json:20231013 declares nexus-staging-maven-plugin:1.6.3 as a build extension. When launcher-zip is assembled, maven-assembly-plugin:3.1.0 builds the models of the dependencies and loads that extension. Its jersey 1.17.1 dependencies inherit jvnet-parent:1, so jvnet-nexus-snapshots comes back; rso-public-grid (from nexus-parent), whose host no longer resolves, comes the same way. org.json is updated to 20260814, whose POM has no such extension. 20240205 to 20260522 still declare it; 20260719 comments it out.

The update changes how numbers that RFC 8259 does not allow are parsed, and 20260719 parses them the same way, so no version without the extension keeps the old behaviour. {"a":01}, {"a":007} and {"a":.5} gave Integer 1, Integer 7 and BigDecimal 0.5 at 20231013; at 20260814 they give the strings "01", "007" and ".5", so getNumber and getInt throw JSONException and optInt returns its default. Valid numbers (1.0, -0, 1e3) parse the same. No code of this repository uses org.json; launcher-zip only bundles the jar.

Other jvnet-parent artifacts

javax.annotation:javax.annotation-api 1.3.1 and 1.2, which some modules and plugin classpaths still use, inherit jvnet-parent:3, which declares jvnet-nexus-snapshots, and jersey 1.18.3 inherits jvnet-parent:4, which declares repositories only in profiles. They cause no warning: javax.annotation-api has no dependencies, so Maven never queries the repository it inherits.

For consumers

• json-web-token, api-descriptor and the modules that depend on them (json-resource, json-resource-http, http-framework/oauth2, the JWT and OpenID Connect JASPI modules, selfservice/stages, ...) no longer bring jaxb-api, jaxb-core, jaxb-impl or javax.activation-api. A module that uses javax.xml.bind and got it only this way has to declare it. Checked on master of the consumers, with the change simulated against their BOMs:
  • OpenIDM: openidm-script (ScriptRegistryService, DatatypeConverter.printHexBinary) and openidm-maintenance (ChecksumFile, HexBinaryAdapter) would no longer compile (openidm-script and openidm-maintenance compile against JAXB that only commons brings in OpenIDM#261). The distribution is not affected: its bundle directory gets the same 336 artifacts, the JAXB ones through jackson-module-jaxb-annotations and opendj-core.
  • OpenIG: not affected, JAXB reaches openig-war through opendj-core and openam-xacml3-schema; the WAR gets the same 278 artifacts.
  • OpenICF: not affected; its zip ships json-web-token and api-descriptor without JAXB, and those jars no longer reference it.
  • OpenDJ and OpenAM declare JAXB themselves.
• The org.json parsing change above reaches OpenAM, which takes the org.json version from this BOM.

Tests

mvn verify of the whole reactor on JDK 27 with network access got to module 97 of 103, the tests of persistit/core, without a failure before it was stopped for lack of memory on the machine. Neither jvnet-nexus-* nor rso-public-grid appears in its log, and the ban-jvnet-parent rule passed in every module it reached. The rest (persistit/core, persistit/ui, script/*, cassandra-embedded) is left to CI, together with the other JDKs of the matrix. The modules that changed passed their tests: json-web-token (328), api-descriptor (290, 24 of them new) and framework-functional-tests (72 integration tests). The rule itself fails json-web-token when it is given a jaxb-api dependency (Found Banned Dependency: javax.xml.bind:jaxb-api:jar:2.3.1, and javax.activation-api:1.2.0 through it). No test in this repository exercises org.json.

[maximthomas]

praise: The change removes the warnings it targets, and the POMs say why.

• pom.xml:766-767 states why the old JAXB coordinates go, and the CI logs bear it out: jvnet-nexus-* and rso-public-grid warnings on 6 rows at the base, on none of the 9 rows at this head.
• persistit/core/pom.xml:87 drops the asm 7.3.1 pin, which would have downgraded the asm 9.1 that rmic 4.2.5 depends on.
• The OSGi Import-Package of json-web-token and api-descriptor is byte-identical to the base (javax.xml.bind;version="[2.3,3)").

---

question (blocking): Is dropping the managed versions of javax.xml.bind:jaxb-api and com.sun.xml.bind:jaxb-core meant to make OpenDJ and OpenAM pin or migrate them when they take this release, or should the parent keep managing them?

pom.xml:766-782

OpenDJ master imports this parent as a BOM (pom.xml:159-166). Its opendj-core/pom.xml:82-89 declares both artifacts without a version, and so does OpenAM master's openam-core/pom.xml:459-466, which gets the BOM through opendj-parent. Neither root POM manages them. A scratch consumer of that shape resolves against the base parent and fails against this head with 'dependencies.dependency.version' for javax.xml.bind:jaxb-api:jar is missing. If the parent should keep managing them, add the entries back next to the new ones. A managed entry is only resolved when some module uses it, and none does here. With the block below, dependency:tree over all 103 modules shows no jaxb-api, jaxb-core or javax.activation-api; the same filter finds them in 34 module trees at the base. So jvnet-parent stays out of this build. If the break is intended, it belongs in the release notes, and the enforcer rule in the next comment pins that these coordinates stay out. I have not checked OpenIDM or other consumers.

            <!-- Still managed for consumers that declare them without a version (OpenDJ opendj-core,
                 OpenAM openam-core); no module of this build depends on them -->
            <dependency>
                <groupId>javax.xml.bind</groupId>
                <artifactId>jaxb-api</artifactId>
                <version>2.3.1</version>
            </dependency>
            <dependency>
                <groupId>com.sun.xml.bind</groupId>
                <artifactId>jaxb-core</artifactId>
                <version>2.3.0.1</version>
            </dependency>

---

suggestion (non-blocking): Nothing in the build keeps javax.xml.bind:jaxb-api and com.sun.xml.bind:jaxb-core out.

pom.xml:766, :1391

The root POM only manages maven-enforcer-plugin 3.0.0-M2 and binds no execution. Any new or bumped dependency that depends on jaxb-api would bring back the jvnet-parent:5 artifact and a second javax.xml.bind jar, and the only symptom would be the warning this PR removes. I ran the rule below with an offline mvn validate. At the base it fails at api-descriptor with Found Banned Dependency: javax.xml.bind:jaxb-api:jar:2.3.1 (and jaxb-core:2.3.0.1). At this head it passes in 92 of 103 modules. The 93rd, httpdump, stopped on an unpackaged sibling snapshot in that validate-only run, not on the rule. It also works with the fix above, because a managed entry is not a resolved dependency.

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-enforcer-plugin</artifactId>
                <executions>
                    <execution>
                        <id>ban-jvnet-jaxb</id>
                        <goals>
                            <goal>enforce</goal>
                        </goals>
                        <configuration>
                            <rules>
                                <bannedDependencies>
                                    <!-- Their parent net.java:jvnet-parent declares the defunct maven.java.net repositories -->
                                    <excludes>
                                        <exclude>javax.xml.bind:jaxb-api</exclude>
                                        <exclude>com.sun.xml.bind:jaxb-core</exclude>
                                    </excludes>
                                </bannedDependencies>
                            </rules>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

Pin: placed in the root <build><plugins> (line 1391, after </pluginManagement>), it makes the base build red and keeps this head green.

---

question (non-blocking): Should json-web-token stay usable by consumers whose BOM manages jakarta.xml.bind:jakarta.xml.bind-api at 3.x/4.x?

commons/json-web-token/pom.xml:100-111, commons/rest/api-descriptor/pom.xml:96-107

Both modules now get javax.xml.bind under the GA that JAXB 3.x/4.x publishes. A consumer that manages that GA at 3.0.1 swaps in a jar with no javax/xml/bind/DatatypeConverter.class. Then SupportedEllipticCurve.java:284 and CrestStringSchema.java:141, :151 throw NoClassDefFoundError, unless javax.xml.bind arrives some other way. OpenAM's features/jaxb3-update-2026-05-19 manages 3.0.1 (pom.xml:1737-1739), and today only opendj-core's jaxb-api hides the problem there. A consumer that also declares jaxb-api/jaxb-core (OpenAM master openam-core) now gets two jars each for javax.xml.bind, com.sun.istack and com.sun.xml.txw2, because Maven cannot mediate across GAs. Minor as long as no consumer relies on this; Major if it should be supported. Either way, worth a line in the release notes. The lasting fix is to drop JAXB from both modules. The main code uses DatatypeConverter on only those three lines, but I have not checked JDK replacements for equivalence.

---

suggestion (non-blocking): Say in the PR description that the org.json 20231013 → 20260814 bump changes how non-RFC numbers parse.

pom.xml:821

OpenAM has no org.json entry of its own, so it gets this version through opendj-parent. I ran the same calls against both jars. {"a":01} and {"a":.5} come back as Integer 1 and BigDecimal 0.5 at 20231013, but as String at 20260814. After that, getNumber/getInt throw JSONException and optInt returns its default. Valid RFC 8259 numbers (1.0, -0) parse the same in both.

---

issue (non-blocking): A JAXB 3 consumer that declares json-web-token before jaxb-runtime now gets txw2 2.3.2 and istack-commons-runtime 3.0.8 under jaxb-runtime 3.0.2.

commons/json-web-token/pom.xml:104-111

The new artifacts use the same GAs as JAXB 3.x/4.x, so Maven keeps one version, and here it picks this module's. All of jaxb-runtime 3.0.2's references to these packages resolve against 2.3.2/3.0.8 except one. com.sun.istack.ByteArrayDataSource implements javax.activation.DataSource in 3.0.8 and jakarta.activation.DataSource in 4.0.1. Unmarshalling inline base64 into a DataHandler/Source property would therefore hit IncompatibleClassChangeError. Not run: that needs a JAXB 3 DataHandler unmarshal, and the OpenAM JAXB 3 branch has no such use. At the base the same hazard depended on jar order through jaxb-core 2.3.0.1.

---

suggestion (non-blocking): No test needs jaxb-impl, txw2 or istack-commons-runtime in json-web-token or api-descriptor.

commons/json-web-token/pom.xml:100-115, commons/rest/api-descriptor/pom.xml:96-111

The main code of both modules uses only javax.xml.bind.DatatypeConverter. Its implementation ships in the API jar (javax/xml/bind/DatatypeConverterImpl.class is in jakarta.xml.bind-api-2.3.3.jar). No class references JAXBContext, Marshaller, com.sun.istack or com.sun.xml.txw2. So removing the runtime trio would leave every test green (inferred, not run).

Pin: either drop the three runtime artifacts from both modules in a follow-up, or, if a consumer relies on getting the JAXB runtime from here, add a test that creates a JAXBContext. Without the trio, that test goes red.

---

suggestion (non-blocking): No test in this repo exercises org.json:json.

pom.xml:821

No main or test source imports org.json.*; launcher-zip only bundles the jar. So no test here can pin the parsing change above. The pin would be a consumer-side test (OpenAM) that parses its own payloads.

---

nitpick (non-blocking): "Three places in the build reach jvnet-parent; this PR removes all three" claims more than the change does.

pom.xml:766

javax.annotation-api 1.3.1 (json-resource-examples, doc-maven-plugin) and 1.2 (the maven-surefire-plugin 3.1.2 classpath) still inherit jvnet-parent:3, which declares jvnet-nexus-snapshots. jersey 1.18.3 (test scope, client-apache-sync/-async) inherits jvnet-parent:4, which declares no repository. They cause no warning because javax.annotation-api has no dependencies, so Maven never queries the repository it inherits. Better wording: "the three paths that make Maven query maven.java.net".

---

note (non-blocking): The Tests section does not match the modules it lists.

• PR description, Tests: json-schema/core "(111, org.json)" and launcher "(9, org.json)" depend on com.googlecode.json-simple, not org.json:json.

[vharseko]

Round 1 is in e697010, and the branch is rebased onto the current master. The description is updated.

1. question (blocking), managed jaxb-api / jaxb-core: kept for consumers. The root POM manages jaxb-api 2.3.1 and jaxb-core 2.3.0.1 again, as on master, with a comment naming opendj-core and openam-core; openam-xacml3-schema declares them the same way. No module of this build depends on them any more (see 3).

2. suggestion, enforcer: added as ban-jvnet-parent in the root <build><plugins>, with javax.activation:javax.activation-api as a third exclude, since its parent com.sun.activation:all:1.2.0 inherits jvnet-parent:1. The rule passed in every module that my local verify reached: 97 of 103, before the run was stopped for lack of memory. CI covers the rest. Given a jaxb-api dependency, json-web-token fails with Found Banned Dependency: javax.xml.bind:jaxb-api:jar:2.3.1 and javax.activation:javax.activation-api:jar:1.2.0. OpenIG, OpenIDM and OpenICF do not use this POM as <parent>, so the rule does not reach them.

3. question, consumers that manage jakarta.xml.bind-api at 3.x/4.x: I took the lasting fix: json-web-token and api-descriptor no longer depend on JAXB. The failure would have been wider than three call sites. seed() runs in the static initialiser of StandardCurve, so ES256, ES384 and ES512 would all have failed.

• SupportedEllipticCurve decodes the seeds itself.
• CrestStringSchema calls DatatypeFactory.newXMLGregorianCalendar(...).toGregorianCalendar(), which is what DatatypeConverterImpl does. parseDateTime first trims XML white space as WhiteSpaceProcessor.trim did; parseDate does not trim.
• I ran the old and the new code side by side over 32 inputs, and each input gives the same result. The inputs cover:
  • " 2016-03-15", a valid date-time and an invalid date;
  • \u000b and  , which both reject, unlike String.trim and strip;
  • years beyond 9999 and 24:00:00.
• The new CrestStringSchemaTest pins 24 of these inputs. It passes at the base and at this head.

So a consumer has no jakarta.xml.bind GA in these modules to override, and gets no second javax.xml.bind jar next to the jaxb-api of openam-core. The OSGi bundles no longer import javax.xml.bind; api-descriptor imports javax.xml.datatype from the JRE instead.

4. suggestion, org.json parsing: confirmed with the same calls and added to the description. 20260719 also comments the extension out, but it parses the same way, so no version without the extension avoids the change.

5. issue, txw2 / istack-commons-runtime under jaxb-runtime 3.0.2: no longer applies, because these modules depend on neither.

6. suggestion, the runtime trio: dropped together with the API. One module did rely on it. framework-functional-tests got javax.xml.bind only through api-descriptor, and rest-assured 2.3.0 loads it in RestAssured.<clinit> (ObjectMapperConfig.<init>:48, NoClassDefFoundError: javax/xml/bind/JAXBException). It now declares jakarta.xml.bind-api 2.3.3 in test scope, and its 72 integration tests pass.

I checked the consumers on master, simulating the change against their BOMs:

• OpenIDM openidm-script (ScriptRegistryService.java:608, DatatypeConverter.printHexBinary) and openidm-maintenance (ChecksumFile.java:45, HexBinaryAdapter) would stop compiling once they take this release; that is openidm-script and openidm-maintenance compile against JAXB that only commons brings in OpenIDM#261. The distribution gets the same bundles.
• OpenIG and OpenICF are not affected.

The description lists this for the release notes.

7. suggestion, no test of org.json: agreed, there is nothing to pin in this repository; the description says so.

8. nitpick, "all three": reworded to "Three dependency paths make Maven query maven.java.net". The description now names javax.annotation-api and jersey 1.18.3, and why they cause no warning.

9. note, the Tests section: fixed. json-schema/core and launcher are no longer listed for org.json; they use json-simple.