Add IMavenProjectFacade#getMojoParameterValue

[laeubi]

Currently we require consumers to go through IMaven for getting Mojo parameters with a maven project. This is both cumbersome and binds us to the MavenProject API from maven-core what complicates Maven 4 migration.

This removes the roundtrip by adding the methods for getting a mojo parameter directly to the facade what later will allow us to exchange the backing implementation much easier.

[github-actions]

Test Results

  345 files  ±0    345 suites  ±0   1h 12m 50s ⏱️ - 6m 27s
  727 tests ±0    709 ✅  - 1  16 💤 ±0  2 ❌ +1 
2 181 runs  ±0  2 131 ✅  - 1  48 💤 ±0  2 ❌ +1 

For more details on these failures, see this check.

Results for commit 88eecdc. ± Comparison against base commit 3741914.

[HannesWell]

This reminds me of

• Improve accessibility of Mojo configuration parameters and (partially) use it in M2E #996

Maybe we should add the supporting methods to IMavenProjectFacade too instead of IMaven?

[laeubi]

Yes I played around with this and pushed a draft now here:

• Mojo facade #2223

The problem is the amount of legacy that one can not easily get around, but I think the IMaven is actually something that could/should die on the long term.

My "vision" here is that we actually have

• IMavenProjectFacade (+ supporting facades)
• IMavenExecutionContext (+ supporting facades)

what wrap the actual maven objects internally and where we have access to these with a service that is provided by a concrete runtime (e.g. Maven 3.10, Maven 3.9, Maven 4, ...) and one can install multiple of those in parallel.

m2e would then select the runtime e.g. based on the model version or things like enforcer rules (like we do already for JVMs)