Update maven to a higher version than 4.0.0-rc-5

[sparsick]

• related to issue Upgrade plugin to use Maven 4 rc5 instead of 4.0.0-beta-3 #249

Following this checklist to help us incorporate your
contribution quickly and easily:

• Make sure there is a JIRA issue filed
  for the change (usually before you start working on it). Trivial changes like typos do not
  require a JIRA issue. Your pull request should address just this issue, without
  pulling in other changes.
• Each commit in the pull request should have a meaningful subject line and body.
• Format the pull request title like [MSOURCES-XXX] - Fixes bug in ApproximateQuantiles,
  where you replace MSOURCES-XXX with the appropriate JIRA issue. Best practice
  is to use the JIRA issue title in the pull request title and in the first line of the
  commit message.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Run mvn clean verify -Prun-its to make sure integration tests checks pass. A more thorough check will
  be performed on your pull request automatically.

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004

• In any other case, please file an Apache Individual Contributor License Agreement.

[slawekjaranowski]

Please also update in .github/workflows/maven-verify.yml

[sparsick]

Tests are failing only when they are run together.

[sparsick]

The root cause of the problem:

EnhancedCompositeBeanHelper in maven-core is responsible for setting the right values for the mojo properties. In this case, both mojos (SourceJarMojo and TestSourceJarMojo) have the same properties. The helper is reusing an internal cache (ACCESSIBLE_FIELD_CACHE) for both mojos, and therefore for the run of the second mojo, the information of the cache is invalid because the field of the second mojo has to be set to accessible, but this step is skipped because the cache is filled.

In the unit tests, a workaround is to add EnhancedCompositeBeanHelper.clearCaches(); as a cleanup step. In the invoker tests it is not possible.

@gnodet: Is this behavior a bug? Or do you have a hint how to avoid it?

[sparsick]

The root cause of the problem:

EnhancedCompositeBeanHelper in maven-core is responsible for setting the right values for the mojo properties. In this case, both mojos (SourceJarMojo and TestSourceJarMojo) have the same properties. The helper is reusing an internal cache (ACCESSIBLE_FIELD_CACHE) for both mojos, and therefore for the run of the second mojo, the information of the cache is invalid because the field of the second mojo has to be set to accessible, but this step is skipped because the cache is filled.

In the unit tests, a workaround is to add EnhancedCompositeBeanHelper.clearCaches(); as a cleanup step. In the invoker tests it is not possible.

@gnodet: Is this behavior a bug? Or do you have a hint how to avoid it?

Already reported: apache/maven#11441
PRs: apache/maven#11425, apache/maven#11433

Thanks to @slawekjaranowski for mentioning it.

[ascheman]

Verified locally that this PR is the right plugin-side fix, and that the residual failures are entirely on the Maven core side (with the fix already merged upstream, awaiting next release):

Plugin source	Maven	Pass / Fail
master HEAD	rc-5	5 / 19
master HEAD	4-master	5 / 19
this PR	rc-5	20 / 4
this PR	4-master	23 / 1

(4-master is apache/maven master HEAD at a166e3fa.)

The 4 residual failures under rc-5 with this PR applied are the outputDirectory == null family (MSOURCES-95, jar-includes-excludes, reproducible, MSOURCES-140) — the EnhancedCompositeBeanHelper.ACCESSIBLE_FIELD_CACHE leak from apache/maven#11441, fixed by apache/maven#11425 (master, merged 2025-11-12) and apache/maven#11433 (maven-4.0.x backport, merged 2025-11-13). Both landed after rc-5 was tagged, so the residuals will disappear with rc-6 / GA.

The 1 residual under 4-master is MSOURCES-140, a pre-existing Groovy verify-script regex bug (unescaped "+ File.separator +"), unrelated to the rc-5 work.

The CONFLICTING status looks like a trivial rebase against current master. Happy to help if useful — anything else blocking review?

[sparsick]

Verified locally that this PR is the right plugin-side fix, and that the residual failures are entirely on the Maven core side (with the fix already merged upstream, awaiting next release):
Plugin source Maven Pass / Fail
master HEAD rc-5 5 / 19
master HEAD 4-master 5 / 19
this PR rc-5 20 / 4
this PR 4-master 23 / 1

(4-master is apache/maven master HEAD at a166e3fa.)

The 4 residual failures under rc-5 with this PR applied are the outputDirectory == null family (MSOURCES-95, jar-includes-excludes, reproducible, MSOURCES-140) — the EnhancedCompositeBeanHelper.ACCESSIBLE_FIELD_CACHE leak from apache/maven#11441, fixed by apache/maven#11425 (master, merged 2025-11-12) and apache/maven#11433 (maven-4.0.x backport, merged 2025-11-13). Both landed after rc-5 was tagged, so the residuals will disappear with rc-6 / GA.

The 1 residual under 4-master is MSOURCES-140, a pre-existing Groovy verify-script regex bug (unescaped "+ File.separator +"), unrelated to the rc-5 work.

The CONFLICTING status looks like a trivial rebase against current master. Happy to help if useful — anything else blocking review?

This comment repeats insight that already was described some comments above.

Nevertheless, I rebased this PR and adjust the title so that is clearer that this PR is waiting for a new 4.0.0 release.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.