Initial review: 2026-09-26. Focused API follow-up: 2026-09-27. Dependabot proposal-policy follow-up: 2026-09-28. Jackson and proposal-routing follow-up: 2026-10-05. Maven 3.10.0 wrapper follow-up: 2026-10-11.
PRs #176 and #188 mixed ordinary build maintenance with changes to intentional tool/API/engine baselines. These decisions apply to the reviewed proposals, not to every future version or security advisory. The 1.x compatibility record and build policy define the contracts being preserved.
Use Maven Bundle Plugin 6.2.0 in place of 6.1.2. Its bnd library moves from 7.3.0 to 7.4.0; the Felix release notes include a fix for dependency resources entering JARs when a module descriptor is present. This is a packaging tool update, not a reason to change bundle identities, OSGi import floors, JPMS names, library dependencies or Java 8 runtime support. Validate generated JAR entries/manifests, original-JAR consumers and deterministic payloads after the change. Felix's Maven plugin is distinct from the deliberately old OSGi framework compatibility fixture.
Use javax.servlet.jsp-api 2.3.3 as the published encoder-jsp provided
dependency. Keep JSP 2.2.1, Servlet 3.0.1 and EL 2.2.5 as the independent minimum
consumer fixture. For the 1.5.0 release, japicmp resolved 1.4.1 against the old support API and the 1.5
artifact against the new one, so inherited API changes are not hidden. The Java 8,
JPMS, OSGi and packaged Jasper checks continue to exercise the original artifacts.
This is a consumer-POM dependency change, not a claim that the minimum supported
JSP container was raised to 2.3.
Use Jakarta Servlet 6.1.0 and Jakarta EL 6.0.1 for the reactor's test classpath. Their test-scope declarations remain visible in the published source POM, but Maven does not propagate them into ordinary consumer dependency graphs and their classes do not enter the adapter JAR. Keep the independent Java 8 packaged-consumer fixture on Jakarta Pages 3.0.0, Servlet 5.0.0 and EL 4.0.0. The old Servlet 6.0.0 and EL 4.0.0 support JARs were explicit japicmp inputs for the 1.4.1 side of the release comparison; the new side used the new test APIs.
After publication, 1.5.1-SNAPSHOT compares against the immutable 1.5.0 artifacts.
Its old support classpaths therefore use JSP 2.3.3, Jakarta Servlet 6.1.0 and
EL 6.0.1, matching that release. This does not change the independent minimum
consumer fixtures or the published provided dependencies.
GitHub's Dependabot alerts for
GHSA-q4xh-88c3-wmh7
and GHSA-wjgm-6hv5-3cvf
surfaced after 1.5.0 publication. Both advisories identify Jackson 3.1.6 as the fixed 3.1 release.
The unpublished Jakarta fixture's executed spring-boot-maven-plugin:4.1.1
depends on spring-boot-buildpack-platform:4.1.1, which brings in Jackson
databind/core 3.1.5. Pin both to 3.1.6 directly in that plugin's dependencies.
Application dependency management does not control Maven plugin realms.
The resolved fixture compile/runtime/test tree has no Jackson databind; its existing JSP-only web starter excludes the JSON starter. Jackson annotations remain test-only via Testcontainers. The core library's independent test-only Jackson 2.22.3 is outside the two affected 2.x ranges. No application exclusion, security suppression or published library dependency is added or changed. Verify both the resolved plugin closure and the packaged browser fixture in CI; a source-POM pin alone does not demonstrate the executed dependency version.
GHSA-wv8q-qhhj-9h54 and GHSA-cxp5-3px4-pw24 affect Jackson databind 3.0.0 through 3.1.6 and are fixed in 3.1.7. GitHub reported both against the Boot plugin-realm pin above. Raise databind and core in that realm to 3.1.7. The scope, CI evidence and unchanged library dependencies from the 2026-09-28 fix still apply. Both advisories also list fixed 2.x releases; the core library's test-only Jackson 2.22.3 is already the fixed 2.22 release. This replaces security PR #231, which failed only on the exact-version policy assertion.
Grouped PR #232 mixed three different decisions:
- Its Jackson 3.2.3 proposal is not accepted. It moves Boot 4.1.1's plugin realm to a minor line that its buildpack platform was not built against, and the 3.1 line already has the fix. The configuration ignores Jackson minor and major version updates; patch and security updates remain eligible.
- Its Maven wrapper 3.10.0 proposal is not rejected, but it is a release-toolchain
change. The configuration now excludes
org.apache.maven:apache-mavenfrom the broad group so it arrives as its own PR. That PR fails by design until it also updates the release enforcer range (pom.xml),scripts/check-wrapper.py,scripts/check-reproducible.py, BUILDING.md, README.md and RELEASING.md, keepsmvnw.cmdLF-normalized in the index (#232 committed CRLF), and records reproducibility evidence for the new Maven version. - Its commons-lang3 3.21.0 build-plugin update is routine and returns in the group.
The Jackson pin remains an exact policy-test value, so every Jackson proposal, including a security update, needs a matching change to that test and this record. Excluding Jackson from the broad group keeps such a proposal from blocking routine updates. Revisit when the Boot parent moves past 4.1.1: if its buildpack platform brings the same or a newer Jackson, remove the pin, its ignore rules and the policy assertion together. Enforcer rules do not inspect plugin realms, so a stale exact pin would silently downgrade Boot's own Jackson.
Grouped PR #257 moves the
Jakarta fixture to Spring Boot 4.1.2. Its spring-boot-buildpack-platform
brings Jackson databind/core 3.1.7, equal to the plugin-realm pin above, so
the pin, its Dependabot ignore and group-exclusion rules, and the exact-version
policy assertion are removed together, as planned. Boot 4.1.2 also manages
Tomcat 11.0.27, newer than the fixture's 11.0.26 override; keeping that
override failed RequireUpperBoundDeps, so it is removed too. A policy test now
fails if either override returns.
PR #256 proposed Jackson 3.1.8 for the pin. No advisory affects 3.1.7, so it is closed in favor of Boot's managed version; a future Boot patch will carry later Jackson releases.
Accept the Maven 3.10.0 distribution proposed by Dependabot PR
#235. That PR failed only
on the wrapper version assertion and re-committed mvnw.cmd with CRLF in the index,
so a separate change completes the checklist above. The wrapper scripts remain
Apache Maven Wrapper 3.3.4 and mvnw.cmd is unchanged. The signing profile now
requires exactly 3.10.0. Ordinary builds keep the [3.9.16,) minimum.
The ZIP's SHA-256 matches the wrapper properties and the SHA-512 published by
Apache, and its detached signature verifies against a key in Apache Maven's
KEYS file. Maven 3.10.0 moves to Resolver 2, breadth-first classpath ordering,
stricter model validation, origin-scoped repository credentials and a Super POM
without plugin management or release-profile
(release notes).
This build already declares its plugin versions, attach-sources/attach-javadocs
executions, encodings and outputTimestamp. Effective POMs from 3.9.16 and 3.10.0
differ only in two unused Super POM plugin-management entries (assembly and
release) and, with performRelease=true, a redundant <inherited>true</inherited>
on the source, Javadoc and deploy plugins. Payload evidence is in the
Maven 3.10.0 validation.
Credential scoping is the one release-path change this review cannot exercise
without the project's Central token. The first signed clean deploy under 3.10.0
should confirm that staging still authenticates before the release relies on it.
| Proposal | Disposition and required evidence before reconsideration |
|---|---|
| Checkstyle 12.3.1 → 14.1.0 | Keep 12.3.1 for the JDK 17 build. PR #188 fails with Java 21 classfile version 65 on Java 17. Reconsider with a separately reviewed build/release-JDK migration and source-policy validation; this is not a claim that the old engine has upstream support. |
| Plexus Utils 3.6.2 → 4.1.0 in GPG/Central plugin dependencies | Keep the reviewed 3.6.2 mitigation. The upstream 4.x migration moves XML utilities to a separate artifact; 4.1 also changes DirectoryScanner default exclusions. A newer major is not a drop-in plugin-realm security fix. Reconsider with actual plugin linkage, isolated signing/bundle/rehearsal evidence, transitive-advisory review and repeatable payloads. |
| javax Servlet 3.0.1 → 4.0.1; EL 2.2.5 → 3.0.0 | Keep the test-only minimum API fixtures. These are not bundled production container implementations. Modern engine coverage is separate; replacing the minimum tests would remove evidence for existing consumers. |
| Jakarta Pages 3.0.0 → 4.0.0 | Keep the published provided Pages 3 API and existing [3.0,4) package ranges. Reconsider only with a reviewed minimum-runtime/API migration, public POM implications and compatibility evidence. |
| Jasper/annotations 9.0.122 or 10.1.60 → 11.0.26 in the isolated tag fixtures | Keep coherent Tomcat 9 (javax) and 10.1 (jakarta) engines. PR #188 fails the javax engine with missing javax.servlet.jsp.tagext.SimpleTagSupport after the Tomcat 11 switch. The optional Boot/browser WAR already exercises Tomcat 11. Patch updates within each engine line come from the separate /jsp and /jakarta Dependabot entries described below. Cross-line migration needs a separate coverage decision. |
A dependency's test/build scope does not dismiss an advisory. Check each finding's actual affected versions, executed path and proposed remedy; use a supported fix or document a specific mitigation/decision. Security alerts remain visible. These proposals do not authorize raising a library or release baseline, and a future security fix may require revisiting a decision above.
Its GPG 3.2.8, Central 0.11.0, versions-maven-plugin 2.22.0, Boot 4.1.1 and optional-app API modernization were already delivered by #180/#185; #187 supplied the reviewed publisher-plugin mitigations. Site is deliberately disabled with an explicit lifecycle version. Doxia/Reflow and dormant project-info/FindBugs/PMD/JXR report tooling were retired in #185, so their old update proposals are obsolete. The versions plugin pin remains; only its old reporting execution was retired. The remaining Felix change is accepted above, and the library API proposals have explicit dispositions above. Close #176 as superseded, without restoring removed tooling or bypassing its failed tests. Replace #188's mixed group with the focused accepted change and this record; a grouped PR closure is not proof that every proposed upgrade was applied.
The configuration excludes twelve coordinates from the broad Maven version-update group: the nine baseline-sensitive coordinates above, the two Boot plugin-realm Jackson coordinates and the Maven distribution used by the wrapper. For the eight of those coordinates with a rejected proposal in #218–#227 and the two Jackson coordinates from #232, it also ignores only the SemVer minor or major version-update classes covered by the decisions above. The Maven wrapper has no ignore rule. The two Tomcat engine coordinates, the other rejected proposals in that range, have their own entries described below. This prevents the weekly job from recreating proposals that merely replace historical comparators, minimum-consumer fixtures, coherent servlet-engine lines, or reviewed tool majors. The accepted Felix Maven Bundle Plugin remains individually updateable.
Apart from the Felix framework fixture and the root entry's two Tomcat rules,
every rule uses update-types, not a version range or an unqualified coordinate
ignore. GitHub documents that update-types affects version updates,
not security updates, so the Maven security-update group and security alerts
remain eligible:
https://docs.github.com/en/code-security/reference/supply-chain-security/dependabot-options-reference#update-types-ignore.
Future minor or major upgrades covered by these rules require a deliberate
compatibility change and manual proposal; remove or narrow the matching rule as
part of that reviewed change. Ordinary Maven changes continue separately.
Dependabot combines repeated Maven coordinates and classifies an update from the
lowest version it found. Consequently, when one coordinate has both a historical
input and a newer current input, a current-line patch may be classified as a
minor or major change from the old floor and suppressed from routine version
PRs. This affects, for example, the split JSP/Jakarta API comparators and the
mixed Plexus Utils plugin realms. It is an explicit noise-versus-automation
tradeoff: manually review those coordinates during dependency and release
maintenance, and always when an advisory appears. The behavior is pinned in
Dependabot's DependencySet
and IgnoreCondition
implementations.
For the Tomcat JSP engine fixtures, that combination writes a wrong version
instead of suppressing one. jsp/ pins Jasper and the annotations API on Tomcat
9.0 (javax) and jakarta/ pins the same coordinates on 10.1 (jakarta). The
reactor scan combined them from 9.0 and wrote 9.0.123 into both modules in #238
and #239, which broke the Jakarta engine; #241 applied each line's patch instead.
The root entry therefore ignores both coordinates outright, so its combined scan
cannot propose a cross-line version or security update. Separate /jsp and
/jakarta entries allow only those two coordinates. A module scan fetches the
module and its parent POM but not sibling modules (Dependabot's Maven
FileFetcher),
so each sees one engine line and proposes its patch release as one grouped pull
request. These entries ignore only major version updates, which would replace
the engine, so security updates remain eligible there. A policy test requires
every reactor module that pins these coordinates to have its own entry on its
expected line.
The root directory monitors the complete Maven reactor once; listing each reactor
module again produced duplicate pull requests. The Tomcat-only /jsp and
/jakarta entries do not duplicate it because the root entry ignores everything
they allow. The standalone compatibility/dependencies Maven project remains a
separate monitored directory.
No security-alert dismissals or automatic merges are introduced. The pre-existing
unqualified Felix framework fixture exception remains scoped and documented in
CI/security operations; it and the root entry's two Tomcat
rules are the only ignore rules without an explicit version-update class.
When a new security proposal or manually raised compatibility change revisits a deferred baseline, compare it with this dated record and current upstream evidence. Do not automatically close a security proposal or infer permanent rejection from an older version decision.