Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Duplicate
-
Affects Version/s: NB_2.1.1
-
Fix Version/s: NB_2.4
-
Component/s: mevenide2-netbeans
-
Labels:None
-
Number of attachments :2
Description
the debug switches are passed to the surefire plugin via the -DargLine=-Xdebug...... property.
However when user defines the argLine parameter for surefire plugin in the pom, the system property is not being evaluated.
There's currently no solution to the problem. One idea that needs some prottyping is to add a method to the embedder that would be able to run the build on top of MavenProject instance instead of a pom file. That we we could dynamically inject the additional debug switches dynamicaly when constructing the MavenProject instance.
-
Hide
- surefire-argline-debug.zip
- 11/Sep/08 1:44 PM
- 138 kB
- Jeff Campbell
-
- surefire-argline-debug/.../jmockit-0.94.jar 438 kB
- surefire-argline-debug/.../jmockit-0.94.jar.sha1 0.0 kB
- surefire-argline-debug/.../jmockit-0.94.pom 0.2 kB
- surefire-argline-debug/.../jmockit-0.94.pom.sha1 0.0 kB
- surefire-argline-debug/pom.xml 2 kB
- surefire-argline-debug/readme.txt 0.4 kB
- surefire-argline-debug/.../ClassWithStaticMethods.java 0.3 kB
- surefire-argline-debug/src/.../Util.java 0.2 kB
- surefire-argline-debug/src/.../UtilTest.java 0.9 kB
-
- SurefirePlugin.java
- 05/Sep/08 3:49 AM
- 42 kB
- Arne And
Activity
when talking to jason, I understood that expressions defined in the parameters shall have priority over what's in the pom. The solution then would be to read the value in pom, enhance it and use as -D<key>=<value> on the command line
A workaround for the issue:
Assuming your surefire setup is like this and your tests need the foobar property set in order to pass.
<project> .... <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.3</version> <configuration> <argLine>-Dfoobar=YES</argLine> </configuration> </plugin> </plugins> </build> </project>
1. Add a profile to the pom.xml with the following <profiles> section
<profiles> <profile> <id>debug</id> <activation> <property> <name>debug</name> <value>true</value> </property> </activation> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.3</version> <configuration> <argLine>-Dfoobar=YES ${argLine}</argLine> </configuration> </plugin> </plugins> </build> </profile> </profiles>
2. Then go to the project's Properties dialog and in the Actions panel, find the "Debug Test" action mapping and add "debug=true" to the list of properties already present.
Then invoking the "Debug file" action on the test class should run the test and stop at breakpoints correctly. It will not in 6.0 betas when using the command-line maven instance for building (issue http://www.netbeans.org/issues/show_bug.cgi?id=119866)
The only downside to the workaround is that you have the foobar property setup at 2 distinct places.
If you don't want to include the profile in the pom.xml file, placing it into $
{basedir}/profiles.xml shall work in the same manner. profiles.xml is not shareable by default, so might be a better location.
in surefire plugin 2.4 there's a new property $
{maven.surefire.debug}which is used to pass debugging params into the forked jvm. These are added to the arg parameter.
We are seeing the same problem. We are using 2.4.3 surefire plugin and it does not seem to help.
Suggested solution, having an 'externalArgLine' readOnly property which also defaults to $
{argLine}, and an 'inheritArgLine' boolean defaulting to true. If user sets 'argLine', it will be appended to 'externalArgLine' if 'inheritArgLine' is true. The inherit can of course be turned off if desirable. See attached suggested implementation. Not sure if it is the ultimate solution, but at least it worked for me, and gives the user of the plugin the possibility to decide what argLine to use
This Bug makes it IMPOSSIBLE to debug a project that uses JMockit tests for its tests because the following needs to be in the pom.xml file:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>-javaagent:"$
/jmockit/jmockit/0.94/jmockit-0.94.jar"</argLine>
<useSystemClassLoader>true</useSystemClassLoader>
<forkMode>always</forkMode>
</configuration>
</plugin>
Jeff, the maven.sufefire.debug property expression shall be working for you. Just replace the argLine in the action mapping dialog (in Project's properties) with maven.sufefire.debug=<the old value of argLine>
See
http://maven.apache.org/plugins/maven-surefire-plugin/examples/debugging.html
however your problem could be with the -javaagent switch, not sure never used it. If you can provide a sample project I can try debugging it.
IN any case for post netbeans 6.5 maven support, I'm planning to use maven.surefire.debug by default.
Attached is a VERY simple Maven jar project that shows our issues for debugging in NetBeans, with a Maven project that requires the <argLine> to be specified. The sample project uses jmockit to run a simple mock test. In this case jmockit requires a <argLine> parameter to run successfully.
Side note (I don't know if this has any impact on a fix)... We do NOT check-in any Netbeans specific files into our source control. Because 50% of us are using NetBeans, 48% of us are using Eclipse, and 2% are using IntelliJ, we do NOT want to check-in any files that are IDE specific (can get really messy to have a bunch of mixed IDE specific files). So..... hopefully the fix will allow a raw Maven project to debug the attached Maven project.
One additional side comment.... half of us that use NetBeans are using 6.5 Nightly with the MevenIDE 4.0.4 plugin and we are STILL seeing the same issue.
Sure, it's not working in 6.5, as I mentioned earlier. I'll be switching to maven.surefire.debug property AFTER 6.5.
So you either use the suggested workaround and will have to live without debugging tests, sorry. Checking the nbactions.xml file (with custom action mappings in netbeans) has no effect whatsoever on eclipse or idea users.
done for netbeans.next - http://hg.netbeans.org/maven-dev/rev/2f6ef9d18287
This bug was transferred to the NetBeans Issuezilla bug tracking system as http://www.netbeans.org/issues/show_bug.cgi?id=154477
closing the issue as duplicate of the newly created one in netbeans.org issuezilla.
Please post your additional comments to the new issue.
postpone, needs changes in maven embedder binaries.