* [MNG-7758] Report dependency problems for all repository - extends ITs
* [MNG-7758] Report dependency problems for all repository - extends ITs
* [MNG-7758] Report dependency problems for all repository - extends ITs
The goal of IT is to "excecise file locking with snapshots"
and not to test model validation.
The IT used dependency had an invalid parent POM w/
wrong packaging and artifactId.
Created IT that does "wrong" (as same directory has once G and once A role), and verify that both level metadata is present. In other words, but none is dropped.
---
https://issues.apache.org/jira/browse/MNG-8106
It uses javadoc:jar goal from locked-down version of Javadoc plugin: Bug is that it refuses to run as 4-alpha-9 returns here language="none". If it would run, it would explode, as project contains java source with intentionally broken javadoc.
---
https://issues.apache.org/jira/browse/MNG-7967
As currently used one is plagued with CVEs etc.
As long as we are stuck on Java8, we cannot move forward
with Jetty, as Jetty 10.x (that is drop in replacement)
is Java 11.
* [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.
The m-p-p depends on m-p-tools-ant and m-p-tools-beanshell as runtime/optional, and the way DownloadMojo resolves every artifact causes that OptionalDependencySelector filter these out even at "collection" stage (as depth >= 2).
Hence, fix DownloadMojo to resolve properly, that actually shifts all the tree "one level up", and hence result is same as in Maven, as the optional dependencies become "first level sibling".
---
https://issues.apache.org/jira/browse/MNG-7667
Guillaume Nodet
Guillaume Nodet
Slawomir Jaranowski
Tamas Cservenak
Jonas Rutishauser
crazyhzm
juulhobert
Tim te Beek
Martin Kanters
Petr Široký
Michael Osipov
Christoph Läubrich