History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: MEVENIDE-435
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Milos Kleint
Reporter: Milos Kleint
Votes: 1
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
mevenide

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

Created: 20/Jul/06 12:50 PM   Updated: Yesterday 03:49 AM
Component/s: mevenide2-netbeans
Affects Version/s: NB_2.1.1
Fix Version/s: NB_2.4

Time Tracking:
Not Specified

File Attachments: 1. Java Source File SurefirePlugin.java (42 kb)



 Description  « Hide
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.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Milos Kleint - 15/Oct/06 12:06 PM
postpone, needs changes in maven embedder binaries.

Milos Kleint - 22/Dec/06 01:35 AM
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

Milos Kleint - 24/Oct/07 03:24 AM
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.


Milos Kleint - 17/Jan/08 01:39 AM
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.

Jeff Campbell - 23/May/08 05:12 PM
We are seeing the same problem. We are using 2.4.3 surefire plugin and it does not seem to help.

Arne And - 05/Sep/08 03:49 AM
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