* the logging framework is extracted into its own jar and moved in the mvn/lib/ directory
* the other daemon jars are moved into the mvn/lib/mvnd directory and not used by maven at all
This makes maven class loader almost identical to the stock maven classloader, but for the logging framework
This is mostly for the integration tests of the Gradle Enterprise Maven extension,
which heavily test dependency resolution and reuse the same GAVs in many test,
e.g. a:b:1.0. It would be a lot of effort to rewrite all those tests and a shame
to restart the daemon every time. So I wanted to ask if you'd consider this flag
to disable the caching altogether.
Use the plexus Launcher to start the daemon server, just like we would
launch a normal Maven process.
This improves compatibility with any extensions or plugins that assume that
their ClassLoader is a ClassRealm.
* Add script mvnd-auto to auto select native or pure java mvnd
* Move fallback logic into main entry script
1. rename native binary to 'mvnd-native-<os>-<arch>'
2. add environment switch MVND_ENTRY_FALLBACK, default 'true' enables
the fallback logic, set to 'false' to force execute the native mvnd.
3. rename mvnd.sh to mvnd
* change entry name on windows
* Add script mvnd-persist-native for moving the native image to the default entry path
* improve platform detect
* fix error on dash
* rollback default entry to the native image
* use MVND_CLIENT switch to control the selection of mvnd client
* improve comment docs as suggestion
* Use muti-release jar to fallback mvnd-client to original maven
The mvnd-client is built to a muti-release jar. The default version of
DefaultClient is compiled against the same target version as the
embedded maven (4.x, so JDK 1.8) which only invoke the MavenCli.main().
The java-11 version is the full qualified mvnd-client.
* update cmd scripts
* embedded maven now works under JDK 1.8
Build SimpleAppender for JDK 1.8 since it is the log appender only
for the embedded maven
Co-authored-by: Guillaume Nodet <gnodet@gmail.com>
* Improve reproducibility of builds by using digest on docker images
* Inline the manifest Multi-Release entry
* Remove unused files
* Switch the groupId to org.apache.maven.daemon and use maven parent pom
* Fix distribution
* Fix ITs
* Fix native build for windows
* Update mvnd to include Maven Resolver 1.7
As mvnd itself is Java8 lang level, it is completely
okay to up resolver to 1.7 (that is java8 as well).
The only reason why Maven 3.8.x CANNOT use resolver
1.7 is that it is still Java7 level.
* Move missing piece to SPI
* Add global exclusions
* Example of mvnd using file locking (of resolver)
* Drop irrelevant
* Upgrade to released 1.7.3
Co-authored-by: Guillaume Nodet <gnodet@gmail.com>
As mvnd itself is Java8 lang level, it is completely
okay to up resolver to 1.7 (that is java8 as well).
The only reason why Maven 3.8.x CANNOT use resolver
1.7 is that it is still Java7 level.
