Maven Surefire

ClassCastException when using testng suiteXmlFile and forkMode=always

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.4.2
  • Fix Version/s: 2.4.3
  • Component/s: None
  • Labels:
    None
  • Environment:
    linux 2.6.22-1-mepis-smp
  • Complexity:
    Intermediate
  • Number of attachments :
    2

Description

The related pom part is:
<profile>
<id>browser</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<suiteXmlFiles>
<suiteXmlFile>src/test/resources/testng-browser.xml</suiteXmlFile>
</suiteXmlFiles>
</configuration>
</plugin>
</plugins>
</build>
</profile>

Issuing mvn -Pbrowser test results in the exception:

java.lang.ClassCastException: java.io.File cannot be cast to java.lang.String
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesForkPerTestSet(SurefireBooter.java:403)
at org.apache.maven.surefire.booter.SurefireBooter.run(SurefireBooter.java:249)
at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:492)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

Any workarounds for this?

Activity

Hide
Andreas Andreou added a comment -

Digging into the source a bit...
Looks like AbstractDirectoryTestSuite.locateTestSets returns a Map<String, SurefireTestSet>
while TestNGXmlTestSuite returns Map<File, String>

SurefireBooter doesn't differentiate between the two, hence the ClassCastException

Show
Andreas Andreou added a comment - Digging into the source a bit... Looks like AbstractDirectoryTestSuite.locateTestSets returns a Map<String, SurefireTestSet> while TestNGXmlTestSuite returns Map<File, String> SurefireBooter doesn't differentiate between the two, hence the ClassCastException
Hide
Andreas Andreou added a comment -

Trivial patch that fixes this issue on the 2.5-SNAPSHOT trunk - all tests pass.

Show
Andreas Andreou added a comment - Trivial patch that fixes this issue on the 2.5-SNAPSHOT trunk - all tests pass.
Hide
Dan Fabulich added a comment -

Well, I think I like the idea of this patch, but I'm a bit creeped out by it, because I can't reproduce your example. We've got a sample integration test that uses suiteXmlFile and it passes (and, more generally, I use that feature all the time). I tried just pasting your snippet into that test and running it with "-P browser", hoping that maybe the problem was with the use of a profile, but no, the test ran just fine on my machine.

Can you provide a minimal example Maven project that reproduces the problem? We can check that into the integration test suite to make sure that issues like this don't crop up again in the future.

Show
Dan Fabulich added a comment - Well, I think I like the idea of this patch, but I'm a bit creeped out by it, because I can't reproduce your example. We've got a sample integration test that uses suiteXmlFile and it passes (and, more generally, I use that feature all the time). I tried just pasting your snippet into that test and running it with "-P browser", hoping that maybe the problem was with the use of a profile, but no, the test ran just fine on my machine. Can you provide a minimal example Maven project that reproduces the problem? We can check that into the integration test suite to make sure that issues like this don't crop up again in the future.
Hide
Andreas Andreou added a comment -

Took me a while to recreate this in a simple project, but i consistently get it when configuring surefire to use a pertest forkMode and defining the profile (and surefire extra configurations) in a child project...

I'm attaching a zip for you to recreate this, from the top level try:
mvn test
and then
mvn -Pbrowser test

Show
Andreas Andreou added a comment - Took me a while to recreate this in a simple project, but i consistently get it when configuring surefire to use a pertest forkMode and defining the profile (and surefire extra configurations) in a child project... I'm attaching a zip for you to recreate this, from the top level try: mvn test and then mvn -Pbrowser test
Hide
Dan Fabulich added a comment -

Using your project I narrowed the problem down more specifically. The issue occurs when using forkMode=pertest aka forkMode=always.

Show
Dan Fabulich added a comment - Using your project I narrowed the problem down more specifically. The issue occurs when using forkMode=pertest aka forkMode=always.
Hide
Dan Fabulich added a comment -

Fixed revision 652188.

Show
Dan Fabulich added a comment - Fixed revision 652188.

People

Vote (6)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: