* building on ubuntu:22.04 produces binaries which require too recent glibc
version (2.32+) and that means the binary no longer works on
older ubuntu versions, like 20.04 and 18.04.
* building on ubuntu:20.04 fixes the problem and the binary again works
on ubuntu 18.04 and 20.04
* also bumped the version in the release workflow which got forgotten
* 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
* currently used versions are deprecated and GitHub is printing
warnings on the actions page, e.g.
"Node.js 12 actions are deprecated.
Please update the following actions to use Node.js 16: actions/checkout@v2,
actions/upload-artifact@v2."
* 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)
* 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
* Run client connection handler inside new thread, fixes#798
* Execute CI build on ubuntu-22.04
* ubuntu-18.04 image is now deprecated and there are brownout periods
being introduced where the builds are failing
* see https://github.com/actions/runner-images/issues/6002 for more
details
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🅱️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.
