The Server was using a SynchrnousQueue to coordinate the main thread
and the background thread that receives the request from the client.
A SynchronousQueue only allows insertions when a corresponding call
to `get` is in progress. However, since the receiver thread is started
before the call to `get`, there was a short time window, where the call
to `queue.offer` could fail and simply return `false`. This return code
was ignored.
A possible solution would have been to call `put` instead of `offer`,
but I decided to replace the queue with a Future, since we only wait
for a single element.
Co-authored-by: Stefan Oehme <st.oehme@gmail.com>
Changes:
* no source change
* (build) expel all versions from child modules: they must be all top level depMgmt or pluginMgmt
* (build) Top POM contains GAVs while child modules GA+scope. This tremendously simplifies maintenance.
* (javadoc) fix Javadoc errors
* (build) remove obsolete profiles and mr-JARs, project is 17+
Updates:
* maven wrapper 3.3.2 w/ scripts
Changes:
* parent POM 42
* unset release where needed (makes com.sun pkg unreachable)
* explicitly index as parent disables "implicit" AP
* remove redundtant stuff
* update dependabot to take care of workflow as well (as mvnd uses own)
* 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
* 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.
* 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
