[MNG-6385] Windows mvn.cmd fail with incorrect command syntax.

[jira-importer]

Eric Barboni opened MNG-6385 and commented

Hi, during some test using Apache Netbeans on windows it appears that some cli can lead to failure of executing mvn.cmd
It was working before on 3.3.9 version.

In the code example (below) if space are removed from path in agentpath section it works.
Otherwise the arguments are cut during evaluation

and the following syntax incorrect will happen
if not "-agentpath:"E:\opensource\space" == "" (

Best Regards

e:\outils\apache-maven-3.5.3\bin\mvn -Dexec.args="-agentpath:\"E:\opensource\space netbeans\netbeans\profiler\lib\deployed\jdk16\windows-amd64\profilerinterface.dll\"=\"E:\opensource\space netbeans\netbeans\profiler\lib\",5140,10 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=C:\Users\barboni\AppData\Local\NetBeans\Cache\dev\mavencachedirs\2080072884\org-netbeans-modules-profiler  -classpath %classpath com.mycompany.mavenproject23.newClass"  -Dexec.executable="C:\Program Files\Java\jdk1.8.0_162\bin\java.exe" -Dexec.classpathScope=runtime -DskipTests=true -Dmaven.ext.class.path="E:\opensource\space netbeans\netbeans\java\maven-nblib\netbeans-eventspy.jar" -Dfile.encoding=UTF-8 org.codehaus.mojo:exec-maven-plugin:1.5.0:exec

---

Affects: 3.5.0, 3.5.2, 3.5.3

Issue Links:

• NETBEANS-245 Profiler fails to launch when using Maven 3.5.x
  ("blocks")

• MNG-5889 .mvn directory should be picked when using --file
  ("is caused by")

• MNG-6346 ... was unexpected at this time when using -f option and path contains brackets

• MNG-6256 Maven script can break if "-f" path contains special characters

2 votes, 7 watchers

[jira-importer]

Gili commented

Here is the output with MAVEN_BATCH_ECHO=on:

cd C:\Users\Gili\Documents\pyramid\server; "JAVA_HOME=C:\\Program Files\\Java\\jdk1.8.0_161" "M2_HOME=C:\\Program Files\\apache-maven-3.5.2" cmd /c "\"\"C:\\Program Files\\apache-maven-3.5.2\\bin\\mvn.cmd\" -Dexec.args=\"-agentpath:\\\"C:/Program Files/netbeans-245/profiler/lib/deployed/jdk16/windows-amd64/profilerinterface.dll\\\"=\\\"C:\\Program Files\\netbeans-245\\profiler\\lib\\\",5140,10 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=C:\\Users\\Gili\\AppData\\Local\\NetBeans\\Cache\\dev\\mavencachedirs\\354137174\\org-netbeans-modules-profiler  -ea -classpath %classpath com.holdmyspot.pyramid.server.ArbitrageBot\" -Dexec.executable=\"C:\\Program Files\\Java\\jdk1.8.0_161\\bin\\java.exe\" -Dexec.workingdir=C:\\Users\\Gili\\Documents\\Pyramid\\server\\target -Dmaven.ext.class.path=\"C:\\Program Files\\netbeans-245\\java\\maven-nblib\\netbeans-eventspy.jar\" -Dfile.encoding=UTF-8 process-classes org.codehaus.mojo:exec-maven-plugin:1.5.0:exec\""

C:\Users\Gili\Documents\pyramid\server>if not "" == "" goto skipRcPre 

C:\Users\Gili\Documents\pyramid\server>if exist "C:\Users\Gili\mavenrc_pre.bat" call "C:\Users\Gili\mavenrc_pre.bat" 

C:\Users\Gili\Documents\pyramid\server>if exist "C:\Users\Gili\mavenrc_pre.cmd" call "C:\Users\Gili\mavenrc_pre.cmd" 

C:\Users\Gili\Documents\pyramid\server>set ERROR_CODE=0 

C:\Users\Gili\Documents\pyramid\server>if not "C:\Program Files\Java\jdk1.8.0_161" == "" goto OkJHome 

C:\Users\Gili\Documents\pyramid\server>set "JAVACMD=C:\Program Files\Java\jdk1.8.0_161\bin\java.exe" 

C:\Users\Gili\Documents\pyramid\server>if exist "C:\Program Files\Java\jdk1.8.0_161\bin\java.exe" goto chkMHome 

C:\Users\Gili\Documents\pyramid\server>set "MAVEN_HOME=C:\Program Files\apache-maven-3.5.2\bin\.." 

C:\Users\Gili\Documents\pyramid\server>if not "C:\Program Files\apache-maven-3.5.2\bin\.." == "" goto valMHome 

C:\Users\Gili\Documents\pyramid\server>if not "_." == "_\" goto checkMCmd 

C:\Users\Gili\Documents\pyramid\server>if exist "C:\Program Files\apache-maven-3.5.2\bin\..\bin\mvn.cmd" goto init 

C:\Users\Gili\Documents\pyramid\server>set MAVEN_CMD_LINE_ARGS=-Dexec.args="-agentpath:\"C:/Program Files/netbeans-245/profiler/lib/deployed/jdk16/windows-amd64/profilerinterface.dll\"=\"C:\Program Files\netbeans-245\profiler\lib\",5140,10 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=C:\Users\Gili\AppData\Local\NetBeans\Cache\dev\mavencachedirs\354137174\org-netbeans-modules-profiler  -ea -classpath %classpath com.holdmyspot.pyramid.server.ArbitrageBot" -Dexec.executable="C:\Program Files\Java\jdk1.8.0_161\bin\java.exe" -Dexec.workingdir=C:\Users\Gili\Documents\Pyramid\server\target -Dmaven.ext.class.path="C:\Program Files\netbeans-245\java\maven-nblib\netbeans-eventspy.jar" -Dfile.encoding=UTF-8 process-classes org.codehaus.mojo:exec-maven-plugin:1.5.0:exec 

C:\Users\Gili\Documents\pyramid\server>set "MAVEN_PROJECTBASEDIR=" 

C:\Users\Gili\Documents\pyramid\server>if not "" == "" goto endDetectBaseDir 

C:\Users\Gili\Documents\pyramid\server>set "EXEC_DIR=C:\Users\Gili\Documents\pyramid\server" 

C:\Users\Gili\Documents\pyramid\server>set "WDIR=C:\Users\Gili\Documents\pyramid\server" 

C:\Users\Gili\Documents\pyramid\server>set FILE_ARG= 

C:\Users\Gili\Documents\pyramid\server>if "-Dexec.args" == "-f" (
set "FILE_ARG=-agentpath:\"C:/Program"  
 shift 
 goto process_file_arg 
) 

C:\Users\Gili\Documents\pyramid\server>if "-Dexec.args" == "--file" (
set "FILE_ARG=-agentpath:\"C:/Program"  
 shift 
 goto process_file_arg 
) 

C:\Users\Gili\Documents\pyramid\server>shift
The syntax of the command is incorrect.

C:\Users\Gili\Documents\pyramid\server>if not "-agentpath:\"C:/Program" == "" (

%~2 definitely doesn't like the spaces. It's not clear to me whether Netbeans' command-line is wrong here or mvn.cmd. I also find it odd that shift is failing.

[jira-importer]

Oleksandr Havenko commented

Issue has been already reported here: https://netbeans.org/bugzilla/show_bug.cgi?id=271059

 

As temporary solution using bundled Maven is recommended...

[jira-importer]

Gili commented

Oleksandr Havenko

1. netbeans.org is dead. The only valid issue tracker now is at issues.apache.org as I have referenced.
2. No one has yet to establish whether the bug is with Netbeans or Maven. My guess is that Maven is at fault because older versions of Maven work fine and newer versions contain a totally-rewritten mvn.cmd file. It's quite possible that this new version does not handle spaces correctly.

Can a Maven committer please investigate this issue?

[jira-importer]

Robert Scholte commented

This issue is caused by MNG-5889. All arguments passed to Maven must be analyzed to verify if it is the --file argument. However, it seems like shift command is ignoring escaped values and splits on spaces without respect of quotes.
So to me this is a Windows issue we might not be able to be solved. Unless somebody can think of another solution.

[jira-importer]

Gili commented

Robert Scholte Can you please provide an example input containing escaped values and the way you expect it to be tokenized?

Looking at https://stackoverflow.com/a/13779820/14731 and the article they link to at the end of the answer, I'm pretty sure we can find a solution. But first, help me understand what behavior you desire and I'll try to help out.

[jira-importer]

Gili commented

Nevermind. I see the problem now. Given:

mvn -Dexec.args="-Dinput=\"output output\""

We want the following tokens:

-Dexec.args=
"-Dinput=\"output output\"

but we actually get:

-Dexec.args
"-Dinput=\"output
output\""

Is that accurate?

[jira-importer]

Gili commented

So, hmm, two questions come to mind:

1. Why did this work in 3.3.9? Meaning, what changed between 3.3.9 and 3.5.2 that all of a sudden command-line parsing is broken?
2. I know this might sound blasphemous and all but... if we can't find a way to make this work using batch files, why not use a native binary instead? That is pretty much guaranteed to work without jumping through all these hoops.
3. Even easier: wrap a dumb batch file around a Java launcher that does more of the heavy-lifting.

[jira-importer]

Robert Scholte commented

1. Before MNG-5889 we ignored the value of --file when looking for .mvn folder, it was done based on the working directory. However, the expected behavior is that .mvn should be calculated relative to the --file value. Because this folder can contain additional jvm arguments for Maven, it must be solved before calling the mainclass of Maven.
2. That would be an idea, but we don't have anything like that in Maven yet. But this seems to be a possibility. I'd say it is about reimplementing shift
3. I guess the wrapper would also be too late regarding jvm args.

ps. With mvn -Dexec.args="-Dinput=\"output output\"" I would expect only 1 argument, namely -Dexec.args="-Dinput=\"output output\"". It should be easy to verify: just have a look the output of the arguments when calling a public static void main(String[] args)

[jira-importer]

Gili commented

Option 3 would give you what you want if you use 2 JVMs. The first would parse the command-line and spawn a second JVM. The obvious downside of this approach is performance, but it's worth measuring how bad it would be.

Another point that comes to mind is that if the command-line does not contain --file you can use the first JVM to invoke Maven directly. Hence, you only take a performance hit for the less common use-case.

Another option is Powershell, but I've never tried it.

[jira-importer]

Robert Scholte commented

When we need to work with 2 JVMs, we should also consider the option of running with a daemon.

[jira-importer]

Gili commented

Agreed, but measure without a daemon first. The overhead might be small enough that it's not worth your while.

I think we have some very good options here with a minimal performance impact. The only question is whether we can find a solution that requires us to write less code :)

Coming back to batch files: another approach worth investigating is grabbing the full command-line using %* and doing the parsing ourselves.

Resources if you want to go in that direction:

• https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/everyone-quotes-command-line-arguments-the-wrong-way/
• https://www.codeproject.com/Answers/176841/DOS-Batch-how-to-parse-command-line-in-DOS-batch-f#answer2