Warning "Unable to create a system terminal" when running maven daemon

[Dunemaster]

Releases 0.0.0
Windows 10

Running any command produces a warning, regardlerss the command succeeds or not

For example:

E:\dev\g5rt\runtime>"E:\Program Files\mvnd\mvnd-windows-amd64" --status
Jun 29, 2020 3:10:51 PM org.jline.utils.Log logr
WARNING: Unable to create a system terminal, creating a dumb terminal (enable debug logging for more information)
UUID PID Port Status Last activity

[gnodet]

It's probably the library jansi-1.18.jar which is missing from the classpath...

[ppalaga]

I was able to reproduce on a Windows VM. I can see jansi-1.18.jar in the lib/ext folder of the distro:

[ppalaga]

As lazy as I am to start my Windows VM, @Dunemaster could you please check if the problem still exists with the freshly released mvnd 0.0.6? https://github.com/mvndaemon/mvnd/releases/tag/0.0.6

[Dunemaster]

@ppalaga it fails with Windows Defender warning

C:\Users\Катя и Вася>mvnd
Sep 29, 2020 11:39:14 PM org.jline.utils.Log logr
WARNING: Unable to create a system terminal, creating a dumb terminal (enable debug logging for more information)
[main] INFO org.jboss.fuse.mvnd.common.DaemonRegistry - Removing 0 daemon stop events from registry
[main] INFO org.jboss.fuse.mvnd.client.DaemonConnector - Starting a Maven Daemon (subsequent builds will be faster)
E:\temp\jpm.16928178981650331864.script(25, 5) Ошибка выполнения Microsoft VBScript: Этот сценарий содержит вредоносное содержимое и был заблокирован антивирусным программным обеспечением.: 'objWMIService.Get(...).Create'

Exception in thread "main" org.jboss.fuse.mvnd.common.DaemonException$StartException: Error starting daemon: uid = 4bdad8b1-6390-4921-b3f0-33535d77560a, workingDir = C:\Users???? ? ????, daemonArgs: "C:\Program Files\BellSoft\LibericaJDK-11\bin\java.exe" -classpath "E:\mvnd\lib\ext\mvnd-common-0.0.6.jar" -Dmvnd.home="E:\mvnd" -Dmvnd.java.home="C:\Program Files\BellSoft\LibericaJDK-11" -Dlogback.configurationFile="E:\mvnd\conf\logging\logback.xml" -Ddaemon.uid=4bdad8b1-6390-4921-b3f0-33535d77560a -Xmx4g org.jboss.fuse.mvnd.common.ServerMain
at org.jboss.fuse.mvnd.client.DaemonConnector.startDaemon(DaemonConnector.java:281)
at org.jboss.fuse.mvnd.client.DaemonConnector.startDaemon(DaemonConnector.java:229)
at org.jboss.fuse.mvnd.client.DaemonConnector.connect(DaemonConnector.java:114)
at org.jboss.fuse.mvnd.client.DefaultClient.execute(DefaultClient.java:188)
at org.jboss.fuse.mvnd.client.DefaultClient.main(DefaultClient.java:71)
Caused by: java.lang.NumberFormatException: null
at java.lang.Integer.parseInt(Integer.java:614)
at java.lang.Integer.parseInt(Integer.java:770)
at org.jboss.fuse.mvnd.jpm.ProcessImpl.readPid(ProcessImpl.java:153)
at org.jboss.fuse.mvnd.jpm.ProcessImpl.create(ProcessImpl.java:137)
at org.jboss.fuse.mvnd.jpm.Process.create(Process.java:53)
at org.jboss.fuse.mvnd.client.DaemonConnector.startDaemon(DaemonConnector.java:277)
... 4 more

[Dunemaster]

"Ошибка выполнения Microsoft VBScript: Этот сценарий содержит вредоносное содержимое и был заблокирован антивирусным программным обеспечением" means "Microsoft VBScript error: this scripte contains malicious content and has been blocked by antivirus software"

[gnodet]

I think the whole org.jboss.fuse.mvnd.jpm.ProcessImpl class could be easily rewritten with the ProcessHandle Java 9 class, that should avoid relying on VB scripts on windows.

[ppalaga]

Using Java 9's ProcessHandle sounds doable. We already use that class in the client. So it would not change the current Java compatibility. Java 11 is required for building the client, but at runtime the native client is Java-agnostic and the server requires Java 8 only.

[gnodet]

That would be even easier. I started adding support for ProcessHandle and the old jpm library in parallel, but it will be easier to get rid of that one.

[famod]

FWIW, I am having the same problem in Git Bash (on Windows) with mvnd 0.0.8.

Btw, I am not seeing the "Improved console output" when building Quarkus. Is this due to the "dumb terminal"?

[gnodet]

@famod could you run with the --debug option and paste the output ? and yes, if the terminal can't be created correctly, the output will certainly be very messy.

[ppalaga]

I'll test tomorrow if this helps #117

[famod]

could you run with the --debug option and paste the output ?

Will do later this week.

and yes, if the terminal can't be created correctly, the output will certainly be very messy.

Well, not at all messy, I just don't see "the status of each build thread on a separate line" (quoted from README).

PS: Now that I read "jansi":

$ echo $MAVEN_OPTS
-Djansi.passthrough=true -XX:TieredStopAtLevel=1 -Xverify:none

https://lists.apache.org/thread.html/r8ea8d63add48508743dcda781928a56032f857279bf520734d41e4b8%40%3Cusers.maven.apache.org%3E
Not sure this is of any help.

[famod]

could you run with the --debug option and paste the output ?

First few lines:

$ mvnd --debug validate
Oct 22, 2020 1:29:16 PM org.jline.utils.Log logr
WARNING: Unable to create a system terminal, creating a dumb terminal (enable debug logging for more information)

Maven Daemon 0.0.8-windows-amd64 (native)
[DEBUG] Reading global settings from settings.xml
[DEBUG] Reading user settings from C:\Users\Falko\.m2\settings.xml
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: C:\_dev\Maven\mvnd-0.0.8-windows-amd64\mvn
Java version: 11.0.8, vendor: AdoptOpenJDK, runtime: C:\_dev\Java\OpenJDK\jdk-11.0.8+10
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
[DEBUG] Reading global toolchains from toolchains.xml
[DEBUG] Reading user toolchains from C:\Users\Falko\.m2\toolchains.xml
[INFO] Error stacktraces are turned on.

Doesn't look very helpful, or does it?

[gnodet]

It does not. I do think the problems comes from the native libraries, so we need to sort that first.

[famod]

export TERM=xterm fixed it for me so I guess you are right that it is related to Jansi.
I am now also seeing the condensed status messages!

[gnodet]

Fixed by 433d414

[famod]

Fix confirmed, thanks!