Repository navigation
Modernization phase 2026 0 - #31
Merged
Merged
Conversation
The OpenAPI archetype referenced two artifact versions that were never
published to Maven Central, so scaffolding failed for anyone without the
original build environment:
- generated pom depended on camel-rest-extensions:0.1.7-SNAPSHOT
(Maven Central's latest release is 0.1.6)
- archetype-post-generate.groovy hardcoded
camel-restdsl-openapi-plugin:0.1.8-SNAPSHOT
(Maven Central's latest release is 0.1.7)
Both are now pinned to the published releases. This brings the OpenAPI
archetype into line with the scheduled archetype, which already referenced
the released 0.1.6.
Fixing those two exposed a third, independent defect: the archetype's
RoutesImplementation.java template did not import DatasonnetExpression,
while the OpenAPI plugin generates route code that calls it. The plugin
only string-replaces a marker comment and never writes imports, so the
generated project failed to compile regardless of which plugin version
ran. Added the missing import.
Also bumped the copyright year in the modified Groovy file, which the
git-backed license header check derives from file history.
This change deliberately upgrades nothing. Camel, Spring Boot, Java, and
the OpenTelemetry agent are all left where they were; version
modernization is deferred to later phases. The goal here is only to
restore a working baseline.
Verified from a cold cache (~/.m2/repository/com/ms3-inc removed):
full reactor build green including both archetype integration tests, plus
a standalone archetype:generate producing a project that compiles and
packages.
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
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