* [MNG-6847] Use diamond operator
Use this link to re-run the recipe: https://app.moderne.io/recipes/org.openrewrite.staticanalysis.UseDiamondOperator?organizationId=QXBhY2hlIE1hdmVu
Co-authored-by: Moderne <team@moderne.io>
* Restore core-it-suite/src/test/resources/mng-5581-lifecycle-mapping-delegate/extension/src/main/java/org/apache/maven/its/mng5581/lifecyclemappingdelegate/TestLifecycleMappingDelegate.java
---------
Co-authored-by: Moderne <team@moderne.io>
The MavenITmng6562WarnDefaultBindings IT tests new Maven4 feature "fail on severity" (for WARN level).
The stub core plugin maven-resources-plugin depends on maven-compat, and it emits plugin validation warning.
BEFORE MNG-7788 was merged, the warnings were logged AFTER build summary and was not picked up by "fail on severity".
AFTER MNG-7788 merged, it causes that warnings breaks the build, as "fail on severity" is set to WARN level.
Fix:
The stub maven-resources-plugin does NOT need to depend on maven-compat, what it really needs is maven-core (for MavenProject).
Fixed ITs to not fail:
- assert only for content, neglect and possible indentation
- do not assert what is NOT warn logged, as later we may log more (IT would be not future proof)
Tested with 3.9.1 and 3.9.2-SNAPSHOT w/ https://github.com/apache/maven/pull/1079 Both passes OK
MNG-7754 changes how plugin validation errors are reported (at end and as a dense report), so ITs needs a bit of lax re formatting and indentation and such.
---
https://issues.apache.org/jira/browse/MNG-7754
Even test is skipped by `@Disabled` annotation
newer surefire schedule it for execution.
When tests are missing in TestSuiteOrdering
are executed as one of first tests in unpredictable order.
* [MNG-7737] IT for profiles
Just a simple IT that would catch issues like Maven 3.9.0
went out with, where files were wrongly interpolated: MNG-7726
---
https://issues.apache.org/jira/browse/MNG-7737
Related IT change, as the change for this issue made MNG-7128 IT
to fail, as it was too eagerly match whole error message string
that has now due MNG-5181 changed.
To fix it, match only the key parts of the expected error message,
that project failed, due transfer failure, as insecure mirror
was blocked. This makes IT assert same thing, but is more
flexible regarding error text change in MNG-5181.
---
https://issues.apache.org/jira/browse/MNG-5185
The MNG-7706 deprecates ancient ArtifactRepository type use to get access to local repository, and issues warning as for any other deprecated Mojo parameters.
But alas, in ITs the MNG-5576 completely unrelated IT there is an assertion to have WARNING-free log. This IT uses the IT-plugins/IT-plugin-expression EvalMojo, that in turn uses the deprecated `${localRepository}` parameter (but does not use it). Result is, Maven 3.9.1 emits a WARNING about use of deprecated parameter and the IT fails.
Further inspection shows, that while EvalMojo injects ArtifactRepository for local repository, there is only one IT that actually uses it, the MNG-4305, but even that one is interested in basedir of the local repository only. So to say, the use of deprecated ArtifactRepository type is not needed at all.
Fix:
* change EvalMojo to not expose in context the localRepository (w/ type ArtifactRepository), but a new expression `localRepositoryBasedir` only, that is injected in non-deprecated way (in real life repoSysSession would be injected, but in IT we keep all super-safe and use Object types).
* adjusted MNG-4305 to use new epxression instead to use object reflection in template to get basedir from ArtifactRepository
* This makes the originally failing MNG-5576 pass, as warning due EvalMojo is gone.
See
https://issues.apache.org/jira/browse/MNG-7706https://github.com/apache/maven/pull/1009
This IT helped a lot to figure out problems around parallel deploy,
and I had locally applied these changes to improve ability to
track down what is actually happening on server side.
Slawomir Jaranowski
Guillaume Nodet
Tim te Beek
Tamas Cservenak
Guillaume Nodet
Martin Kanters
Petr Široký
Michael Osipov
Christoph Läubrich