Maven Surefire

Calculation of relative path to xref is wrong

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0 Report Plugin
  • Fix Version/s: 2.5
  • Component/s: Maven Surefire Report Plugin
  • Labels:
    None
  • Environment:
    WinXp, Java5
  • Testcase included:
    yes
  • Patch Submitted:
    Yes
  • Number of attachments :
    3

Description

The calculation of the relative path to xref is wrong! I.e. it fails with the current config:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-report-plugin</artifactId>
    <version>2.1-SNAPSHOT</version>
    <configuration>
        <linkXRef>true</linkXRef>
        <xrefLocation>target/site/framework-tests/xref</xrefLocation>
        <outputDirectory>target/site</outputDirectory>
    </configuration>
</plugin>

In appended patch I've changed the following:

  • Parameter outputDirectory is now a java.io.File so there is even a chance to find out the relavtive path for the config above.
  • I've replaced the code where the relative path is calculated with the static method invocation of my new util class (tests for util class included).

Cheers,
Martin

Issue Links

This issue depends upon:
SUREFIRE-264 XRef links do not work with aggregated reports on windows Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Martin Zeltner added a comment -

Sorry. Here's the full patch. Previously the two new files where not included. Please ignore the first patch file.

Cheers,
Martin

Show
Martin Zeltner added a comment - Sorry. Here's the full patch. Previously the two new files where not included. Please ignore the first patch file. Cheers, Martin
Hide
Permalink
Maarten Winkels added a comment -

I think changing the outputDirectory to a java.io.File is a good solution. Dropping it in favour of the reportOutputDirectory that already exists in the parent class is (in my opinion) even better.

The main problem with it being a string is that it becomes os dependant: The default value is ${project.build.directory}/site which on windows should be ${project.build.directory}\site.

With the use of:

PathTool.getRelativePath( reportOutputDirectory.getAbsolutePath(), xrefLocation.getAbsolutePath() );

I see no real problems, it also used in the CheckStyle plugin.

Show
Maarten Winkels added a comment - I think changing the outputDirectory to a java.io.File is a good solution. Dropping it in favour of the reportOutputDirectory that already exists in the parent class is (in my opinion) even better. The main problem with it being a string is that it becomes os dependant: The default value is ${project.build.directory}/site which on windows should be ${project.build.directory}\site. With the use of: PathTool.getRelativePath( reportOutputDirectory.getAbsolutePath(), xrefLocation.getAbsolutePath() ); I see no real problems, it also used in the CheckStyle plugin.
Hide
Permalink
Dan Fabulich added a comment -

This bug needs "To Reproduce" instructions; I can't reproduce a relative path problem with the current 2.4 surefire. Is this bug even still there?

Show
Dan Fabulich added a comment - This bug needs "To Reproduce" instructions; I can't reproduce a relative path problem with the current 2.4 surefire. Is this bug even still there?
Hide
Permalink
Benjamin Bentmann added a comment -

Steps to make it fail:

  1. unpack the attached mini project
  2. get yourself a Windows box to test it on
  3. cd into the project base directory
  4. run "mvn test"
  5. run "mvn jxr:test-jxr surefire-report:report-only"
  6. browse to the surefire report and try to follow the hyperlink to the failed test "BasicTest"

The main problem with it being a string is that it becomes os dependant

Dan, that's the point you need take into mind. The linking fails because determineXrefLocation() feeds PathTool.getRelativePath() with the following parameters:

basedir  = ${basedir}/target/site
filename = ${basedir}\target\site\subdir\xref-test

Note the different file separators. Due to these, the check filename.startsWith( basedir ) in PathTool fails and the method quits immediately, errorneously reporting the relative path as "".

Show
Benjamin Bentmann added a comment - Steps to make it fail:
  1. unpack the attached mini project
  2. get yourself a Windows box to test it on
  3. cd into the project base directory
  4. run "mvn test"
  5. run "mvn jxr:test-jxr surefire-report:report-only"
  6. browse to the surefire report and try to follow the hyperlink to the failed test "BasicTest"
The main problem with it being a string is that it becomes os dependant
Dan, that's the point you need take into mind. The linking fails because determineXrefLocation() feeds PathTool.getRelativePath() with the following parameters: 
basedir  = ${basedir}/target/site
filename = ${basedir}\target\site\subdir\xref-test
Note the different file separators. Due to these, the check filename.startsWith( basedir ) in PathTool fails and the method quits immediately, errorneously reporting the relative path as "".
Hide
Permalink
Kristian Rosenvold added a comment -

This issue seems to have been fixed in r635090. I have verified this in 2.7.2-SNAPSHOT and am unable to reproduce it, even on a Windows box.

Show
Kristian Rosenvold added a comment - This issue seems to have been fixed in r635090. I have verified this in 2.7.2-SNAPSHOT and am unable to reproduce it, even on a Windows box.

People

Vote (2)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved:

Time Tracking

Estimated:
15m
Original Estimate - 15 minutes
Remaining:
15m
Remaining Estimate - 15 minutes
Logged:
Not Specified
Time Spent - Not Specified
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.