This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Product Version: NetBeans IDE Dev (Build 201605260002) Java: 1.8.0_92; Java HotSpot(TM) 64-Bit Server VM 25.92-b14 Runtime: Java(TM) SE Runtime Environment 1.8.0_92-b14 System: Windows 7 version 6.1 running on amd64; UTF-8; en_US (nb) User directory: C:\dev\Netbeans\user\dev Cache directory: C:\dev\Netbeans\cache\dev 1. Create Maven project with the following code sniplet in pom.xml: <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>exec-maven-plugin</artifactId> <version>1.4.0</version> <executions> <execution> <id>default-cli</id> <goals> <goal>exec</goal> </goals> <configuration> <executable>java</executable> <arguments> <argument>-Dkey=value</argument> <argument>-classpath</argument> <classpath/> <argument>Server</argument> <argument>run</argument> </arguments> </configuration> </execution> </executions> </plugin> 2. Project -> Properties -> Actions -> Run project -> Set Properties -> "exec.args=-classpath %classpath ${packageClassName} Server run" 3. Try running the project. 4. Notice that Netbeans executes mvn.cmd "-Dexec.args=\"-Dkey=value Server run -classpath %classpath Server run" Expected behavior: exec.args defined in Netbeans' project properties should replace exec.args as defined by pom.xml. Actual behavior: The two values are merged incorrectly, causing runtime failures.
Ah ha! This is a regression. Version 8.1 works fine. Increasing priority accordingly.
the merge was of the exec-maven-plugin arguments was introduced in #259028 > 4. Notice that Netbeans executes mvn.cmd "-Dexec.args=\"-Dkey=value Server run -classpath %classpath Server run" > Expected behavior: exec.args defined in Netbeans' project properties should replace exec.args as defined by pom.xml. > Actual behavior: The two values are merged incorrectly, causing runtime failures. - is the problem caused by "Server run" being twice in the mvn cmd? what happens if you remove it from the action definition? - or is there more to the issue? thanks
(In reply to Tomas Stupka from comment #2) > - is the problem caused by "Server run" being twice in the mvn cmd? what > happens if you remove it from the action definition? > - or is there more to the issue? > > thanks Yes, the problem is that "Server run" shows up twice in the mvn cmd. If I remove it from the action definition I end up with: "-Dexec.args=\"-Dkey=value Server run -classpath %classpath\"" Which is still wrong because classpath is treated as an argument of the application (it doesn't get picked up by the JVM).
Commenting on #259028, I also prefer the idea of Netbeans setting some other variable (e.g. "ide.debug") and then letting "exec.args" as defined by pom.xml insert that variable wherever it sees fit. For people running outside the IDE, you'd assign "ide.debug" to an empty string by default. I believe that if pom.xml sets "ide.debug" to empty string and the command-line sets "-Dide.debug=override" then the latter value will get used.
> Yes, the problem is that "Server run" shows up twice in the mvn cmd. If I remove it from the action definition I end up with: > "-Dexec.args=\"-Dkey=value Server run -classpath %classpath\"" > Which is still wrong because classpath is treated as an argument of the application (it doesn't get picked up by the JVM). so is it the order of the arguments in -Dexec.args
> so is it the order of the arguments in -Dexec.args Yes. JVM parameters, such as "-classpath" need to show up before application arguments. But like I said before, I think that any merging process is inherently fragile and we are better off exposing a separate Maven property and let the user integrate it into pom.xml as they see fit.
fixed in jet-main #2876d4376222
> But like I said before, I think that any merging process is inherently fragile and we are better off exposing > a separate Maven property and let the user integrate it into pom.xml as they see fit. like already mentioned in #259028 - using a property to solve the problem seems nontrivial in other aspects