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.
Co-authored-by: Guillaume Nodet <gnodet@gmail.com>
Fixing terminal on Windows.
changes:
* added missing jline-native to dist
* up GraalVM to 22
* introduce `--diag` on client
* up SVM version, cleanup of GraalVM params
Fixes#1032
And use JNI (and FFM) instead.
Changes:
* use DefaultClient from master (thanks @gnodet !)
* drop jansi (as DefaultClient should not depend on it)
* introduce two new jline3 terminal backends: jni and ffm (used on Java 22+)
* tested/verified (thanks @wendigo )
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.
