Maven Surefire

build fails with ClassNotFoundException, BUT the class IS there!

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.3
  • Fix Version/s: 2.4
  • Component/s: classloading, Junit 4.x support
  • Labels:
    None
  • Environment:
    Windows XP SP2, Java SE 6, Maven 2.0.5
  • Complexity:
    Intermediate
  • Number of attachments :
    3

Description

JUnit 4 and POJO tests give ClassNotFoundException exceptions in test phase of the build (pom.xml is attached).
The console output gives a hint: JUnit 3.8.1 is appended to the surefire-booter forked JVM classpath instead of JUnit 4 (I tried it with junit-4.0, 4.1 and 4.2). When I try a POJO test case I get the same error.

Also attached are the outputs from the command lines for JUnit4 and POJO test cases
mvn -X clean test > mvn.log

Attachments

  1. Text File
    mvn-junit4.log
    24/Mar/07 12:17 PM
    34 kB
    Ivan Mikushin
  2. Text File
    mvn-pojo-test.log
    24/Mar/07 12:17 PM
    34 kB
    Ivan Mikushin
  3. XML File
    pom.xml
    24/Mar/07 12:17 PM
    1 kB
    Ivan Mikushin

Issue Links

This issue relates to:
SUREFIRE-467 NoSuchMethodError UrlUtils.getURL when using JDK3 for testing Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jose CHILLAN added a comment -

Hi,

I had the same issue but I solve it easily : surefire simply doesn't work if the full path or the directory where your artifacts
are contains non plain english chars. This is the case in your logs so just move your code in a simple path (no space, only
standard ASCII char) and it will work.
Some other plugins have the same problem, such as docbook, and so on...

Show
Jose CHILLAN added a comment - Hi, I had the same issue but I solve it easily : surefire simply doesn't work if the full path or the directory where your artifacts are contains non plain english chars. This is the case in your logs so just move your code in a simple path (no space, only standard ASCII char) and it will work. Some other plugins have the same problem, such as docbook, and so on...
Hide
Permalink
Ivan Mikushin added a comment -

Yeah, you are right.
Great thanks!
IMO, it's a bug anyway

Show
Ivan Mikushin added a comment - Yeah, you are right. Great thanks! IMO, it's a bug anyway
Hide
Permalink
Anders Hammar added a comment -

The problem is how the URLs for the class loader are being encoded. This is done in org.apache.maven.surefire.util.UrlUtils.getURL(File).

If that method is changed into the one below it works for me (using a path for my maven project that includes non plain English chars):

UrlUtils.java
...
    public static URL getURL( File file )
        throws MalformedURLException
    {
        // encode any characters that do not comply with RFC 2396
        // this is primarily to handle Windows where the user's home directory contains spaces,
    	// but also to handle non plain English characters
        URI uri = file.toURI();
        return uri.toURL();
    }

I'm not familiar with creating patch files. Anyone who can help me?
Also, a complete list of other plugins with the same problem would be great so that the same fix could be submitted for those.

Show
Anders Hammar added a comment - The problem is how the URLs for the class loader are being encoded. This is done in org.apache.maven.surefire.util.UrlUtils.getURL(File). If that method is changed into the one below it works for me (using a path for my maven project that includes non plain English chars):
UrlUtils.java
...
    public static URL getURL( File file )
        throws MalformedURLException
    {
        // encode any characters that do not comply with RFC 2396
        // this is primarily to handle Windows where the user's home directory contains spaces,
    	// but also to handle non plain English characters
        URI uri = file.toURI();
        return uri.toURL();
    }
I'm not familiar with creating patch files. Anyone who can help me? Also, a complete list of other plugins with the same problem would be great so that the same fix could be submitted for those.
Hide
Permalink
Anders Hammar added a comment - - edited

My bad. When reading the documentation more carefully I see that pre-1.4 JDKs should be supported. My fix above includes JDK 1.4+ stuff.

EDIT: Why do we need to be compatible with JDK 1.3? Maven 2 requires JDK 1.4 to execute, so I don't see the need for this plugin to support JDK 1.3. Or am I missing something?

Show
Anders Hammar added a comment - - edited My bad. When reading the documentation more carefully I see that pre-1.4 JDKs should be supported. My fix above includes JDK 1.4+ stuff. EDIT: Why do we need to be compatible with JDK 1.3? Maven 2 requires JDK 1.4 to execute, so I don't see the need for this plugin to support JDK 1.3. Or am I missing something?
Hide
Permalink
Dan Fabulich added a comment -

Fixed revision 597766

Show
Dan Fabulich added a comment - Fixed revision 597766

People

Vote (1)
Watch (1)

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.