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
In test, we check if pom files are read only once.
When we update plugin or dependencies in test,
number of read items can change again.
So should be good enough to check if duplicate items exist in log file.
This change extends Bootstrap IT (1st IT that fills in local repo) to hunt down some plugins that are bound in lifecycles provided by Maven under test.
Changes:
* the Bootstrap IT invokes only the phase where DownloadMojo is bound
* DownloadMojo (the "bootstrap") changed to do "this or that": it either resolves all artifacts from provided file OR collects plugins for given project packaging plugin versions provided by tested Maven default lifecycle.
* Split more Bootstrap project POMs, now we have 4 modules, we can add more (even extension if needed)
---
https://issues.apache.org/jira/browse/MNG-7667
Update Jetty to latest 9.4.50, last Java 8 capable version. Apply API changes and also remove jetty-servlet as ITs does NOT use servlet aspect of Jetty HTTP server.. This will simplify our lives in future, to make jump to later versions (that are Java 11+). Also, drop jetty-servlet as test do not use any servlet aspect.
---
https://issues.apache.org/jira/browse/MNG-7665
* Modernize IT plugins to use annotations
* Align some tests to maven 3.8.6
# Conflicts:
# core-it-suite/src/test/resources-filtered/bootstrap.txt
# core-it-suite/src/test/resources/mng-3221/report/pom.xml
# core-it-suite/src/test/resources/mng-3428/pom.xml
# core-it-suite/src/test/resources/mng-3530/build-path/plugin/pom.xml
# core-it-suite/src/test/resources/mng-3530/pom-property/plugin/pom.xml
# core-it-suite/src/test/resources/mng-3530/resource-object/plugin/pom.xml
# core-it-suite/src/test/resources/mng-3704/maven-mng3704-plugin/pom.xml
# core-it-suite/src/test/resources/mng-3743/plugins/maven-mng3743-check-plugin/pom.xml
# core-it-suite/src/test/resources/mng-3743/plugins/maven-mng3743-report-plugin/pom.xml
# core-it-suite/src/test/resources/mng-3743/project/pom.xml
# core-it-suite/src/test/resources/mng-4086/repo/org/apache/maven/its/mng4086/maven-it-plugin-a/0.1/maven-it-plugin-a-0.1.pom
# core-it-suite/src/test/resources/mng-4086/repo/org/apache/maven/its/mng4086/maven-it-plugin-a/0.2-SNAPSHOT/maven-it-plugin-a-0.2-20090315.124508-1.pom
# core-it-suite/src/test/resources/mng-5581-lifecycle-mapping-delegate/extension/pom.xml
# core-it-suite/src/test/resources/mng-7310-lifecycle-activated-in-specified-module/project/pom.xml
* Add dependencies on all support artifacts to ensure multithreaded builds can use correct ordering
* Add missing dependencies on plexus-utils
* Fix for mng-7335 test
* Fix ITs for maven 4
* Rename Component -> TestComponent to leave room for the annotation
* Upgrade a few plugin versions
* Upgrade some JDK requirements to 1.8
* Remove unwanted parentheseses
* Convert the last mojo to annotations
* Force timestamped build
* Fix ITs following Component -> TestComponent rename
* Remove commented block
* Remove versions infered from plugin management
* The implementation parameter is not supported anymore
* Align maven core version
* Fix bad merge
- old m-resource-p can fail in multi thread executions
- test project use aggregation - so we need provided configuration in each module
- replace deprecated method
- add message for assertions
* Move ITs to JDK 8 / JUnit 5
* Add missing tests, move disabled test comments to the test itself
* Add unreferenced tests (Unreferenced tests are automatically added at the beginning, but it looks more coherent to add them anyway)
* Reset verifier to run fresh test in MNG-5581
* Remove useless lines
* Minimize changes in imports
Co-authored-by: Michael Osipov <michaelo@apache.org>
This test checks whether version range resolution with multiple repositories maps releases onto repos that
are not enabled for releases.
Tested with 3.8.x, 3.9.x and master. Reliably fails without the MNG-7529 fix applies, reliable passes with
the fix applied.
Maven 4.0.x has some new code which takes care of the terminal width to adjust
the output. The number of dots can thus vary when running the tests locally.
Co-authored-by: Guillaume Nodet <gnodet@gmail.com>
This closes#187 and closes#175.
* [MNG-7474] SessionScoped beans should be singletons for a given session
* Upgrade Maven Resources Plugin to 3.2.0 in MNG-6720/MNG7335 to avoid
ConcurrentModificationException
* Clean up IT a bit
This closes#177
The HttpServer helper is used by two ITs:
* MavenITmng7470ResolverTransportTest
* MavenITmng5771CoreExtensionsTest
And it logs in case of MNG7470 for unknown reason. My bet would
be some static initing happening as side effect of OTHER ITs that
use Jetty directly, like MavenITmng5868NoDuplicateAttachedArtifacts.
Anyway, this sorts out Jetty logging.
An IT for Maven 3.9+ that "exercise" both resolver transport: wagon and native (so we have 2 tests both forcing transport with `-Dmaven.resolver.transport` one wagon (which is default, but setting is there to be explicit) and once native.
It builds a project that needs a plugin (to pull it will use set transport), and that plugin will use resolver as well to resolve set artifact. If any of these fails, maven project fails.
Related fix: https://github.com/apache/maven/pull/732 (jn maven-3.9.x and master)
Most IT's that used e.g. ${version} are now
disabled from Maven 4.0.0-alpha-1 onward.
The others have been updated not to use
'prefixless' expressions anymore.
Closes#141.
This may resolve the connection issues we sometimes see in GitHub
Actions where the Maven process that is being tested cannot connect
to the Jetty server that was just started.
This closes#107
* Modify ITs to pass with Maven 4
* Disable MavenITmng3719PomExecutionOrderingTest for Maven 4 because it
deliberately relies on duplicate plugin declarations
This closes#103
Central from global settings with 'file:' comes first and is ignored by the
mirrorOf definition. The next central definition is ignored too due to
MNG-7018/MNG-5984. As long as these issues aren't resolved we need to mirror
even local repos to make the IT work as intended.
This closes#92
Use a fresh, preconfigured verifier which has global settings set.
This issue can be observed when Maven is ran with MNG-4645 where
no preconfigured Maven Central is in global settings.
This closes#94
Use a fresh, preconfigured verifier and do not clear CLI options because
on clear all preconfigurations, especially global settings are gone.
This issue can be observed when Maven is ran with MNG-4645 where
preconfigured Maven Central is lost in global settings.
This closes#93
Guillaume Nodet
Guillaume Nodet
Tamas Cservenak
Slawomir Jaranowski
Petr Široký
Michael Osipov
Christoph Läubrich
Konrad Windszus
Konrad Windszus
Tom Scholten
Konrad Windszus
Martin Kanters
Henning Schmiedehausen
Hervé Boutemy
Giovanni van der Schelde
Marc Wrobel
Jesse Glick
Olivier Lamy
Maarten Mulders
Gabriel Belingueres
Christian Schulte
Arturo Bernal
rfscholte
Sylwester Lachiewicz
Falko Modler
Christoph Hümbert