chore: update java-parent to 1.3.0

[herbie-bot]

What this is

com.open-elements:java-parent 1.2.1 → 1.3.0. Three things arrive with it, and each has a
consequence in this repository — this PR handles all three rather than only bumping the number.

1. project.build.outputTimestamp is now fixed centrally

The parent sets it to the literal 2026-09-10T00:00:00Z and release.sh rewrites it per release.
Its own comment is worth repeating, because it is easy to misread: this is not a build time — it
identifies the java-parent release an artifact was built against. For "when did this source state
come into being", the Git-Commit-Time manifest entry from the full-build profile is the answer.

This is what docs/TODO.md tracked as "in progress separately" and what spec 018's design listed as
an open prerequisite. Both are updated to say it shipped, and the TODO entry now states plainly which
bullets remain (build-info, the SBOM output path, ARG GIT_COMMIT in the application Dockerfiles) —
those are what spec 018 actually needs before it can read anything.

Verified, not assumed: the reactor was built twice and the artifact checksums compared.

8426cc69…  spring-services-core-1.4.0-SNAPSHOT.jar
e2c6da0d…  spring-services-scim-1.4.0-SNAPSHOT.jar

Identical across both runs — the reproducible-build claim holds here.

2. The OpenAPI stack is BOM-managed

1.3.0 imports springdoc-openapi-bom and swagger-bom, and pins the swagger-ui webjar,
because springdoc's BOM manages springdoc artifacts only and the Swagger versions it is built against
are not part of that contract.

This repository does not use springdoc, but it does use io.swagger.core.v3:swagger-annotations-jakarta
— pinned locally at 2.2.29 through its own property. That property and the explicit <version> in
spring-services-core are removed, so the artifact now resolves to 2.2.47 through the parent.

Not cosmetic: the parent warns that a split Swagger stack throws NoSuchMethodError at runtime,
because swagger-core calls annotation members that only exist in its own release. Keeping a local
pin while the org standard moves on recreates that hazard for any consumer that also pulls springdoc.

[INFO] +- io.swagger.core.v3:swagger-annotations-jakarta:jar:2.2.47:compile

3. Spotless now formats with <lineEndings>UNIX</lineEndings>

The parent notes that this alone does not make a child's sources jar LF-clean: Git still checks files
out per the local core.autocrlf, so a build on a Windows default install would publish CRLF sources
and break reproducibility. It expects each child to carry a .gitattributes; this repository had
none, so one is added with * text=auto eol=lf plus binary exclusions.

It is diff-neutral today — every tracked file was checked and none contains CRLF. It is protection
against a contributor on a differently configured machine, not a cleanup.

4. Version properties the parent now manages are removed

All five remaining properties in the reactor POM were checked against the parent's
dependencyManagement and against their actual usage here:

Property	managed by parent	referenced here	verdict
jspecify.version	yes (org.jspecify:jspecify 1.0.0)	spring-services-core	removed
testcontainers.version	yes (testcontainers-bom import)	nowhere	removed
slack-api-client.version	no	slack	kept
wiremock.version	no	core, dbbackup, search	kept
mcp-sdk.version	no	mcp (2×)	kept

testcontainers.version was not merely dead code: a property of that name in this POM shadows the
parent's, and the parent's BOM import resolves through it. Both sat at 2.0.5, so the effect was
invisible — but the next testcontainers bump in java-parent would have been silently pinned back to
the old version by a value nobody remembers maintaining. jspecify had the same shape, plus an
explicit <version> in spring-services-core, now gone too.

The comment above the remaining three says why they stay: they are the versions the parent does not
manage, and redefining a parent-managed property here is the trap to avoid.

Resolution after the change is unchanged — jspecify:1.0.0, all five org.testcontainers artifacts
at 2.0.5, swagger-annotations-jakarta:2.2.47.

Verification

• Full reactor build with tests: BUILD SUCCESS, 134 tests, no failing test class.
• project.build.outputTimestamp resolves to 2026-09-10T00:00:00Z in a child module; parent version
  resolves to 1.3.0.
• Two consecutive builds produce byte-identical jars (checksums above).
• No Spring Boot change: the parent keeps spring-boot.version at 3.5.14, so Spring Security stays
  6.5.10 and nothing in the security code is affected.

One pre-existing issue this PR deliberately does not fix

mvn spotless:check fails — on main as well as on this branch, with the identical three files
(src/test/java/com/example/app/Order.java, StarterAutoConfigurationIntegrationTest.java,
StarterTestApp.java). I compared the violation lists before and after the bump: the new parent adds
none. Since Spotless has no lifecycle binding in this build, CI does not fail on it. Left for a
separate, formatting-only change so this PR stays reviewable — say the word and it gets one.

🤖 Generated with Claude Code