mevenide

cannot debug tests when surefire's argLine paramter used in pom

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major 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.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Milos Kleint added a comment -

postpone, needs changes in maven embedder binaries.

Show
Milos Kleint added a comment - postpone, needs changes in maven embedder binaries.
Hide
Permalink
Milos Kleint added a comment -

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

Show
Milos Kleint added a comment - 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
Hide
Permalink
Milos Kleint added a comment -

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.

Show
Milos Kleint added a comment - 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.
Hide
Permalink
Milos Kleint added a comment -

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.

Show
Milos Kleint added a comment - 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.
Hide
Permalink
Jeff Campbell added a comment -

We are seeing the same problem. We are using 2.4.3 surefire plugin and it does not seem to help.

Show
Jeff Campbell added a comment - We are seeing the same problem. We are using 2.4.3 surefire plugin and it does not seem to help.
Hide
Permalink
Arne And added a comment -

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

Show
Arne And added a comment - 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
Hide
Permalink
Jeff Campbell added a comment -

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:"${settings.localRepository}/jmockit/jmockit/0.94/jmockit-0.94.jar"</argLine>
<useSystemClassLoader>true</useSystemClassLoader>
<forkMode>always</forkMode>
</configuration>
</plugin>

Show
Jeff Campbell added a comment - 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:"${settings.localRepository}/jmockit/jmockit/0.94/jmockit-0.94.jar"</argLine> <useSystemClassLoader>true</useSystemClassLoader> <forkMode>always</forkMode> </configuration> </plugin>
Hide
Permalink
Milos Kleint added a comment -

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.

Show
Milos Kleint added a comment - 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.
Hide
Permalink
Jeff Campbell added a comment -

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.

Show
Jeff Campbell added a comment - 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.
Hide
Permalink
Jeff Campbell added a comment -

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.

Show
Jeff Campbell added a comment - 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.
Hide
Permalink
Milos Kleint added a comment -

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.

Show
Milos Kleint added a comment - 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.
Hide
Permalink
Milos Kleint added a comment -

done for netbeans.next - http://hg.netbeans.org/maven-dev/rev/2f6ef9d18287

Show
Milos Kleint added a comment - done for netbeans.next - http://hg.netbeans.org/maven-dev/rev/2f6ef9d18287
Hide
Permalink
Jaromir Uhrik added a comment -

This bug was transferred to the NetBeans Issuezilla bug tracking system as http://www.netbeans.org/issues/show_bug.cgi?id=154477

Show
Jaromir Uhrik added a comment - This bug was transferred to the NetBeans Issuezilla bug tracking system as http://www.netbeans.org/issues/show_bug.cgi?id=154477
Hide
Permalink
Milos Kleint added a comment -

closing the issue as duplicate of the newly created one in netbeans.org issuezilla.
Please post your additional comments to the new issue.

Show
Milos Kleint added a comment - closing the issue as duplicate of the newly created one in netbeans.org issuezilla. Please post your additional comments to the new issue.

People

Vote (1)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.