Remove deprecated setCompilerVersion() call - #1088
Closed
elharo wants to merge 170 commits into
Closed
Conversation
…l` (apache#243) Co-authored-by: Guillaume Nodet <gnodet@gmail.com>
…Timestamp is empty (apache#244)
No need to call System.getPropery with magic names 'path.separator' and 'line.separator'. Java does that for us and provides friendly methods/fields for them.
Initialize patchModules = new LinkedHashSet with capacity. Signed-off-by: Sergey Ponomarev <stokito@gmail.com>
Bumps commons-io:commons-io from 2.7 to 2.14.0. --- updated-dependencies: - dependency-name: commons-io:commons-io dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
apache#271) * Rewrite the plugin using standard `javax.tools` API instead of Plexus. Other aspects that are rewritten include incremental build mechanism and how the overwriting of `module-info.java` in tests is handled. For details and impact on users, see pull request description at apache#271 * Temporarily disable the MCOMPILER-346 integration test. It will be re-enabled after Maven 4.0.0-beta-6 release. apache/maven#1865 * Remove the replacement of `/` by `\` on the Windows platform in GLOB syntax. It appears that the GLOB matcher expects `/` even on Windows. * Add a log at the error level when the compiler threw an exception instead of returning the Boolean `false` value. Adjust what is the cause and what is the suppressed exception. * Set the `maven-plugin-testing-harness` version to 4.0.0-beta-2. * Dummy change for forcing a new CI build.
Bumps org.ow2.asm:asm from 9.7 to 9.7.1. --- updated-dependencies: - dependency-name: org.ow2.asm:asm dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Remove version properties for dependencies that are not used. Revert "Temporarily disable the MCOMPILER-346 integration test."
Bumps [apache/maven-gh-actions-shared/.github/workflows/maven-verify.yml](https://github.com/apache/maven-gh-actions-shared) from 4 to 5. - [Commits](apache/maven-gh-actions-shared@v4...v5) --- updated-dependencies: - dependency-name: apache/maven-gh-actions-shared/.github/workflows/maven-verify.yml dependency-version: '5' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
There was a problem hiding this comment.
Pull request overview
This PR removes a deprecated, no-op call to CompilerConfiguration.setCompilerVersion() from AbstractCompilerMojo.executeReal(), eliminating a deprecation warning while keeping the deprecated compilerVersion parameter for backward compatibility with existing user configurations.
Changes:
- Removed the
compilerConfiguration.setCompilerVersion(compilerVersion);call during compiler configuration setup. - Kept the deprecated
compilerVersionMaven parameter intact so users still receive a deprecation warning (without breaking builds).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
* Fix documentation issues 1-12 * Revert site.xml change: keep 'Older projects with module-info' --------- Co-authored-by: opencode <opencode@localhost>
This is a port of 8d3d6ac from 3.x.
Move the Maven 4 version property to the current RC and pin the same
version explicitly in the Verify workflow, so CI does not depend on the
maven4-version default in maven-gh-actions-shared.
maven-testing is versioned by ${mavenVersion}, and its
org.apache.maven.api.plugin.testing package was relocated to
org.apache.maven.testing.plugin. Deprecated shims remain under the old
name, but ProducedArtifactStub's shim is a bare no-arg subclass, so the
five-argument constructor CompilerMojoTestCase uses is not inherited and
the test sources no longer compile. Point the imports at the new package.
mvn test: 16 tests, 0 failures.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
asfMavenTlpPlgnBuild passes siteMvn straight to doCreateTask, which does
jenkinsEnv.mvnFromVersion(os, "${maven}"). A Groovy List interpolates to
the literal "[4.0.x]", which matches no case in mvnFromVersion and falls
through to "default: return 'maven_3_latest'" - so the site stage silently
ran on Maven 3. The maven: parameter is unaffected because the shared
library iterates that list before passing each element.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A pure rename, so that git records it and `git log --follow` and `git blame` still reach the history of each page after the conversion that follows. The content is still APT at this point and the site does not build between the two commits.
Converted with doxia-converter and then cleaned up by hand:
- <<<code>>> becomes backticks, <<bold>> becomes **bold**, {{{url}text}}
becomes [text](url)
- the ASF license header becomes a single block HTML comment
- the page keeps a Velocity reference, so it stays a .vm. Velocity reads ## as
a line comment and would silently swallow every ATX heading below level one,
so subsections use setext underlines and anything deeper is wrapped in
#[[ ... ]]#
Verified by building the site before and after: the rendered page is
unchanged apart from <b>/<i> becoming <strong>/<em> and quotes in prose
picking up the Markdown module's typographic substitution.
…equested that information.
Git records a rename plus a rewrite in one commit as a delete and an add, which stops 'git log --follow'. Splitting the rename out keeps the history. Please merge or rebase rather than squash. Generated-by: Claude Opus 5 (1M context)
doxia-converter cannot target FML usefully - the questions come out as link-reference syntax rather than headings, the [top] back-links become links to a nonexistent 'top' page, and the contents links lose their # anchors. The page is written out by hand instead. Explicit <a name> anchors keep the existing deep links working. All 1 still resolve. Where an id was not a valid XML name, Doxia rewrote it at render time via DoxiaUtils.encodeId; the anchors written here reproduce that rendered form, not the raw attribute. Verified by building the site before and after and comparing the set of anchors the generated faq.html actually serves: every anchor present before is still present after, the <head> is byte-identical, and every link target on the page is unchanged. site.xml needs no edit: src/site/fml/faq.fml and src/site/markdown/faq.md both render to faq.html. FML generates a [top] back-link after each answer; those are dropped rather than hand-written, which is the only rendering loss. The anchors are written <a id> rather than <a name>: maven-site-plugin 3.21.0 silently drops a name attribute from inline HTML, leaving the build green and every deep link broken. The id form works on every version and is the correct HTML5 spelling. Generated-by: Claude Opus 5 (1M context)
ascheman
requested changes
Aug 10, 2026
ascheman
left a comment
ascheman
left a comment
Contributor
There was a problem hiding this comment.
Thanks for chasing down these deprecation no-ops. The code change itself is correct: CompilerConfiguration.setCompilerVersion() is a deprecated no-op (plexus-compiler no longer evaluates it — a forked javac's version is auto-detected via <executable>), and this was the only place in src/main that read the compilerVersion parameter. So the removal is behavior-preserving, and keeping the @Deprecated field for backward compatibility is the right call.
One thing to address before this goes in — because this PR is what makes it wrong:
With this call gone, compilerVersion is now fully inert (nothing reads it), yet the docs still present it as a working feature. In src/site/markdown/examples/compile-using-different-jdk.md.vm:
The
compilerVersionparameter can be used to specify the version of the compiler that the plugin will use. However, you also need to setforktotruefor this to work.<fork>true</fork> <executable><!-- path-to-javac --></executable> <compilerVersion>1.3</compilerVersion>
After this PR that <compilerVersion>1.3</compilerVersion> line does nothing. The <fork> + <executable> mechanism still selects the JDK and is fine to keep — it's just the <compilerVersion> element (and the sentence describing it) that's now dead. Could you drop those from the example in this same PR, so we don't finish deprecating the parameter while the docs still advertise it? Happy to approve once that's in.
elharo
force-pushed
the
remove-deprecated-compilerVersion-call
branch
from
August 22, 2026 11:09
abc3b2c to
0376c3a
Compare
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.
CompilerConfiguration.setCompilerVersion()is deprecated and no longer evaluated by the underlying compilers. ThecompilerVersionfield inAbstractCompilerMojois already@Deprecatedwith this Javadoc:This removes the no-op call to eliminate the deprecation warning while keeping the
@Deprecatedfield for backward compatibility — users who still setmaven.compiler.compilerVersionwill get a deprecation warning but not a build error."