Bump maven.version from 4.0.0-rc-4 to 4.0.0-rc-5
Bumps `maven.version` from 4.0.0-rc-4 to 4.0.0-rc-5.
Updates `org.apache.maven:maven-plugin-api` from 4.0.0-rc-4 to 4.0.0-rc-5
Updates `org.apache.maven:maven-model` from 4.0.0-rc-4 to 4.0.0-rc-5
Updates `org.apache.maven:maven-core` from 4.0.0-rc-4 to 4.0.0-rc-5
Updates `org.apache.maven:maven-resolver-provider` from 4.0.0-rc-4 to 4.0.0-rc-5
Updates `org.apache.maven:maven-embedder` from 4.0.0-rc-4 to 4.0.0-rc-5
Updates `org.apache.maven:maven-cli` from 4.0.0-rc-4 to 4.0.0-rc-5
Updates `org.apache.maven:maven-api-di` from 4.0.0-rc-4 to 4.0.0-rc-5
Updates `org.apache.maven:maven-jline` from 4.0.0-rc-4 to 4.0.0-rc-5
Updates `org.apache.maven:maven-logging` from 4.0.0-rc-4 to 4.0.0-rc-5
Updates `org.apache.maven:apache-maven` from 4.0.0-rc-4 to 4.0.0-rc-5
- [Release notes](https://github.com/apache/maven/releases)
- [Commits](https://github.com/apache/maven/compare/maven-4.0.0-rc-4...maven-4.0.0-rc-5)
---
updated-dependencies:
- dependency-name: org.apache.maven:maven-plugin-api
dependency-version: 4.0.0-rc-5
dependency-type: direct:production
update-type: version-update:semver-patch
- dependency-name: org.apache.maven:maven-model
dependency-version: 4.0.0-rc-5
dependency-type: direct:development
update-type: version-update:semver-patch
- dependency-name: org.apache.maven:maven-core
dependency-version: 4.0.0-rc-5
dependency-type: direct:production
update-type: version-update:semver-patch
- dependency-name: org.apache.maven:maven-resolver-provider
dependency-version: 4.0.0-rc-5
dependency-type: direct:production
update-type: version-update:semver-patch
- dependency-name: org.apache.maven:maven-embedder
dependency-version: 4.0.0-rc-5
dependency-type: direct:production
update-type: version-update:semver-patch
- dependency-name: org.apache.maven:maven-cli
dependency-version: 4.0.0-rc-5
dependency-type: direct:production
update-type: version-update:semver-patch
- dependency-name: org.apache.maven:maven-api-di
dependency-version: 4.0.0-rc-5
dependency-type: direct:production
update-type: version-update:semver-patch
- dependency-name: org.apache.maven:maven-jline
dependency-version: 4.0.0-rc-5
dependency-type: direct:production
update-type: version-update:semver-patch
- dependency-name: org.apache.maven:maven-logging
dependency-version: 4.0.0-rc-5
dependency-type: direct:production
update-type: version-update:semver-patch
- dependency-name: org.apache.maven:apache-maven
dependency-version: 4.0.0-rc-5
dependency-type: direct:production
update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>
* Replace junit-platform-maven-plugin with maven-exec-plugin
The junit-platform-maven-plugin is no longer maintained and causes issues
with Maven 4.0.0-rc-5 due to stricter request validation.
This commit refactors the JUnitPlatformTest to use maven-exec-plugin instead:
- Removed JUnitPlatformTest and junit-platform test project
- Extended ExecOutputTest with a new cleanTestInheritIO() test method
- Added new execution to exec-output/pom.xml using exec:java goal with inheritIo=true
- Created HelloWorld.java class for testing inheritIO functionality
The refactoring maintains the same test coverage while using a more
maintainable plugin.
Related to #1477 and sormuras/junit-platform-maven-plugin#117
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Sylwester Lachiewicz <slachiewicz@apache.org>
Co-authored-by: Guillaume Nodet <gnodet@gmail.com>
The JvmTestClient pushed things to system properties and then did not clean up them. This went invisible, as long as user did not have user-wide extensions like smart-builder that suddenly was not filtered out anymore from tested mvnd daemon and caused havoc.
Changes:
* def client helper method emits "prev state" for properties it altered
* JvmTestClient uses this map to restore properties
* MavenConfIgnore ITs modified to still ignore takari smart builder as well...
Fixes#1357
Seems MSC fork does not allow pushes from users who have commit rights on forked maven-mvnd, so am incorporating @ascheman changes here as well.
This PR is:
* fixes from PR https://github.com/apache/maven-mvnd/pull/1252
* plus fix SO isse (self injected cache)
* plus migrated whole daemon to Maven DI (from javax.inject) except those that override Sisu components
* ported latest Maven changes
Experiment PR to figure out why MacOS GH runners keep failing with transport related (SSL handshake abort, HTTP timeouts) errors. As we know linux and windows boxes are in Azure, while macos boxes are somewhere else, and we get regularly real strange errors like "SSL handshake errors", "HTTP timeout error (against Central?)", so suspicion is on JDK transport (in HTTP/2 mode).
Experiments:
* force apache transport (HTTP/1.1) - ✔️
* force JDK transport into HTTP/1.1 - 🟥
* use big timeout for connectTimeout - ✔️
Conclusion: for ITs we will for now increase the default (10sec) `connectTimeout` Resolver configuration, as it seems too low.
Port Maven 3.9.7 config and new properties (session.root/top)
into Daemon m39.
The IT got this property as it triggers exception (failure)
if mvn39 could not "discover" top directory.
Fixes#910
* Add configuration to send build scans to https://ge.apache.org
* Add `.mvn` directories to IT tests projects that lack one
Some of the integration tests to do not have `.mvn` directories and
search up the project structure until they find the `.mvn` directory
of the root project.
This change adds `.mvn` directories with empty `maven.config` files so
that the sample projects in VCS will be as close as possible to those
executed during integration testing
* Make the default (non-native) build work again
* the renamed test is supposed to use the native binary, but it was
being picked up by surefire, because of its name. For non-native builds
(e.g. without -Pnative) the test would fail as the native
binary does not exist
* Add GitHub job for for default (non-native) build
* Fix core export provider
Since https://github.com/apache/maven/pull/616, the default
CoreExportProvider no longer uses the provided CoreExports,
but instead tries (and fails) to discover them itself.
This change fixes that by providing our own custom instance
of CoreExportProvider. This allows core extension to contribute
exported artifacts and exported packages again, like it used to
do before the Maven 4.x upgrade.
* Add integration tests for API-providing extensions
https://issues.apache.org/jira/browse/MNG-7586
* Remove CliMavenPluginManager which has the changed needed in alpha-3
* Align slf4j api with maven
* Make sure the invoker being called from IT reuses the settings from the invoker running the IT
* Fix IT when mrm is disabled
* Fix InvalidingPluginRealmCache
Co-authored-by: Guillaume Nodet <gnodet@gmail.com>
* Set default max heap size to null
Let the JVM decide the max heap size instead of using hardcoded defaults
to match the behaviour of vanilla Maven.
* Add ITs for verifying max heap behaviour
- By default no max heap should be set
- If configured via jvm.config then max heap should be set but not mvnd.maxHeapSize
- If configured via mvnd.maxHeapSize then max heap should be set
* Remove defaults memory options
* Add missing test project
* Fix too small heap size
* Fix tests
Co-authored-by: Ashhar Hasan <hashhar_dev@outlook.com>
