The daemon was implementing the legacy plexus.interactivity Prompter interface, which Maven 4 no longer
calls. Instead, it needs to implement the new maven.api Prompter interface. This also simplifies the code,
since the legacy prompter handling is now done by Maven core and it delegates to the new interface if an
old plugin uses it.
Also, prompting was skipped on dumb terminals for some reason. This meant that prompting could not be
tested with automated tests using ProcessBuilder. It also meant that piping input into mvnd on the terminal
wouldn't work. This made it inconsistent with regular Maven, which supports promting on a dumb terminal.
I've reactivated it, which makes the prompting integration tests for our Maven extension pass again.
There was also a missing console flush before sending the response to the daemon, which could lead to
inconsistent output, where the newline was sometimes printed before and sometimes after the next line from
the daemon.
Fixes#1292
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
Adopt to https://github.com/apache/maven/pull/2134
Goal is to be able to perform required customizations to Terminal, but also "raw streams" (as Maven acts on false, while mvnd on true).
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
* fix: Daemon lifecycle must be shared with daemon invoker
As long daemon is alive, the daemon invoker must be kept
alive as it holds the "resident" object graph of Maven.
* Add hack
This is a bug in resident invoker
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)
