Fixes#1248
When running with mvnd.noDaemon=true, the connectNoDaemon() method was
setting up various system properties but missing the crucial
MVND_JAVA_HOME property. This caused the Server constructor to fail
with 'The system property mvnd.java.home is missing'.
The fix adds the missing MVND_JAVA_HOME property in connectNoDaemon()
using the same value as JAVA_HOME from parameters.javaHome().
Changes:
- Add MVND_JAVA_HOME property setup in DaemonConnector.connectNoDaemon()
- Add NoDaemonTest to verify the fix works correctly
The solution follows the existing pattern used for other properties
in the same method and ensures noDaemon mode works as expected.
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
Just use Nisse, as it is already in place, plus it does not require git checkout either.
Fixes#1306
Nota bene: this does not solve "rebuilding from tarball", as output will still not contain revision (will be empty). Just like Maven, MavenDaemon also relies on git to provide SCM hash shown in version.
But the build will not fail at least, and Maarten will be able to rebuild from tarball, but the build output will be different from that built from git checkout.
mvnd still had mvn3 like code, just drop it and let base parser
do the work. All the mvnd needs is filtering.
Discriminating based on XML file hashes.
Fixes#1280
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
Changes:
* Cumulative update of GH flow
* Graal update
* Add concurrency
* Add -V to see what maven is used
* Use same Java version for def build
* Apply @gzm55 advice
The modern glibc from 2.34 had two breaking changes: move all api in lib{pthread,dl,rt}.so into libc.so, new static start up code breaking the runtime compatibility for old glibc (<2.34). See https://developers.redhat.com/articles/2021/12/17/why-glibc-234-removed-libpthread for more info.
This commit has 3 changes to overcome these changes:
- override gcc path to redefine glibc symbols on the fly in the generated .o by graalvm when linking
- provide a dynamic startup code to support both old and modern runtime glibc
- add needed dynamic libraries: lib{pthread,rt,dl}.so.
* 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
* fix typo in method names
* add a test for the other *toHumanReadable method
* replace StringBuilder usage with simple concatenation
where applicable (for fixed length strings)
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.
* 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>
