Modernization phase 2026 2 - #12
Merged
Merged
Conversation
Raise the compiler to release 21 and bring the Maven plugin toolchain to
current stable versions:
maven.compiler.release -> 21 (replacing source/target)
maven.version 3.3.9 -> 3.9.16
maven-plugin-annotations 3.6.0 -> 3.15.2
maven-plugin-plugin 3.6.0 -> 3.15.2 (both declarations)
maven-compiler-plugin 3.8.0 -> 3.15.0
maven-plugin-testing-harness 3.3.0 -> 3.5.1
Correction to an earlier assessment: this project was NOT compiling at
Java 7. The properties said maven.compiler.source/target 1.7, but the
build section declared maven-compiler-plugin with an explicit
<source>11</source><target>11</target>, and plugin configuration wins over
properties. The effective level was 11 and the 1.7 properties were dead
text. Both are now replaced by a single maven.compiler.release property so
there is one place to look.
Deliberately NOT moving to the 4.0.0-beta / 4.0.0-rc line that Maven
Central reports as "release" for these artifacts. This plugin has to run
under the Maven 3.9.x that builds the archetypes; the newest stable 3.x
line is the correct target.
Two things broke, both in the plugin descriptor generation rather than the
code:
- maven-plugin-plugin 3.6.0 fails with "Unsupported class file major
version 65" once sources compile to Java 21 bytecode - its bundled ASM
predates Java 21. Fixed by the version bump.
- maven-plugin-plugin 3.7+ requires an explicit goalPrefix when the
artifactId does not match the maven-*-plugin / *-maven-plugin
convention. "camel-restdsl-openapi-plugin" does not, so the prefix is
now declared as camel-restdsl-openapi. This affects only the short
invocation form; the archetype invokes by full coordinates.
The generator sources themselves needed no changes. All 4 existing tests
still pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
… compile check
The headline defect: every project this plugin generated failed to compile
against Camel 4, at every REST route.
appendProducer emitted `.to(direct("op").getUri())`. Camel 4 removed
getUri() from the endpoint builders, so the generated RoutesGenerated
failed with "cannot find symbol: method getUri()" once per operation - 19
errors for the petstore fixture. Camel 4 provides
RestDefinition.to(EndpointProducerBuilder), so the builder is now passed
directly: `.to(direct("op"))`. Golden files updated accordingly.
Nothing in the existing test suite could have caught this. All four tests
compared generated characters against committed text; none compiled the
result. The plugin's own source and the source it emits are different
things, and only the former was ever verified.
Added GeneratedCodeCompilesTest, which wraps the emitted route bodies in an
EndpointRouteBuilder subclass and compiles them with the in-process
javax.tools compiler against camel-endpointdsl and camel-datasonnet 4.18.4
(new test-scoped dependencies). It runs for both a 3.0 and a 3.1
specification and is the test that found the getUri() regression. The
emitted request-validation line is excluded from the compile check because
it references OpenApi4jValidator from camel-rest-extensions, whose Camel 4
build is not yet released; coupling an unreleased artifact into this test
would tie the two repositories together mid-migration.
swagger-parser-v3 2.0.24 -> 2.1.47:
- OpenAPI 3.0 output is byte-for-byte unchanged. The existing golden
files matched without modification, so 3.0 behavior did not move.
- OpenAPI 3.1 previously did not work at all. Verified empirically by
pinning the parser back to 2.0.24: it returns null for a 3.1 document
and generateOperationInfoList died with a NullPointerException. With
2.1.47 the same document parses and generates correctly.
Note: the task specified 2.1.27; 2.1.47 is the current stable release and
was used instead.
Added an OpenAPI 3.1 fixture exercising constructs that do not exist in
3.0 - type arrays for nullability, numeric exclusiveMinimum - with golden
files and operation-list coverage.
Also fixed: an unparseable specification produced a bare
NullPointerException, because the parser returns null rather than throwing
for an unreachable path, malformed YAML, or an unsupported version. It now
fails with a message naming the document. Regression test added.
Version set to 0.2.0-SNAPSHOT and CHANGELOG.md added. Not published.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…headers CI runners (the reason every phase branch would have failed review): - actions/setup-java@v1 -> @v4, actions/checkout@v2 -> @v4. The v1/v2 actions are Node 12/16 era and no longer execute on current GitHub runners at all, so these workflows were dead regardless of Java. - JDK 11 -> 21 on every build and deploy job. Sources now compile with maven.compiler.release 21, so a JDK 11 runner could not build them. - Dropped the java: [ '1.8', '11', '15' ] matrix. Those targets are below the project baseline and the matrix would have failed on all three legs. Maven wrapper 3.6.3 -> 3.9.16 (wrapperVersion 3.3.4). Maven 3.6.3 predates Java 17 and misbehaves on JDK 21, so anyone cloning and running ./mvnw hit a toolchain older than the code it was building. The refreshed wrapper uses distributionType=only-script, which removes the checked-in .mvn/wrapper/maven-wrapper.jar binary - the distribution is fetched by the script instead. Verified: ./mvnw reports Apache Maven 3.9.16 and builds. License headers no longer derive their year from git. The header template used ${license.git.copyrightYears}, computed per file from git history by license-maven-plugin-git. Editing any file therefore moved its expected year and failed the build with "Some files do not have the expected license header" - a message that never explains the cause. It cost time in every phase so far and would cost it for every contributor. The template is now a static "2020-2026", the license-maven-plugin-git dependency is removed, and all existing headers were normalized with license:format. Consequences: the check is deterministic, and CI no longer needs fetch-depth: 0 (that setting existed only so the git plugin could read per-file history), so checkouts are shallow and faster. Tradeoff accepted: per-file "last modified" accuracy in headers is lost in exchange for a check that does not fail on every edit. Re-running license:format after a year bump restores accuracy in one commit. Not changed: tavros-camel-components still has setup-java@v1 on JDK 11. It is the retirement candidate in phase 5 and gets no CI work. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
upgrading java and libraries