Support TestNG

waitting for the feature

I posted this to maven dev mailing list but I think it's way too busy to picked up by anyone..

If no one is currently working on this I plan on making a stab at it, with the hopes that someone will pipe in and change my plan of direction if I'm going the wrong way. P.S. If you are working on testng integration I won't be sad at all, in fact I'd be very very happy not to have to do it

From what I read in nabble archives I saw that someone mentioned integrating it into surefire directly, which sounds like a win-win situation to me judging from the surefire code I looked at for duping into a testng plugin. I do have some questions though:

-) I'm guessing that the test runtime should dynamically figure out what sort of classes/jvm version it is working with to execute the correct testing framework? I can't imagine any form of property setting logic being fun for anyone. Hopefully this won't be as painful to do as it sounds

-) I noticed that the surefire reports plugin is still going through codehaus, is this just a temporary infrastructure management sort of thing, or should I plan on having the testng reporting aspect of things hosted as a seperate plugin download? I'm sure the reporting aspect part will be the least of my problems, but I wanted to address it ahead of time so an answer was available when I was ready for it.

Please feel free to jump in and stop/correct any assumptions written here. I also wanted to re-iterate that I won't be sad at all if someone else already owns this

Jesse: we welcome your contributions!

I believe there is already an experimental testng plugin here: http://jira.codehaus.org/browse/MOJO-33

However, I think direct support in surefire is much better.

for q1) that'd be best. surefire should be able to detect testng stuff and run testng, or junit, or whatever. It may be the case that you are able to force the provider through a property. I don't know if we need to support multiple testing frameworks in a single run.

2) Is there any reason to have different output to the existing report? I'd hope we could just generate one output file, and have one reporting plugin.

Arggh! Fine...

1) Your method sounds good. Attempt a best-guess at runtime, and if the engine chooses the wrong type the user can force it with a property.

2) Awesome. I like not writing code whenever possible I didn't even invest any real thought into it, but there's probably nothing there that a little xslt love can't fix.

Arggh? The experimental plugin is really just something you could refer to. Last time I checked it didn't compile. However, maybe you could work with Kaare on the surefire based integration.

No XSLT should be necessary. We just need to define one output format, and ensure all of the surefire runners output that format and the report can read that format.

Yay! This is turning out to be a lot easier than I thought.

Question: Does anything in the maven dependency runtime have the ability for me to optionally include one or another artifact depending on the jvm version running? I've basically got an issue where I have to either include the jdk14 or jdk15 version of testng depending on the runtime.

One solution that I came up with is bundling the core set of classes/interfaces for testng into a sort of testng-core artifact, and then force the user to specify which testng implementation they want to use. The surefire runtime would also report errors if more than one testng artifact impl was specified.

I'm going to pass this along to cedric as well.

You can use profiles to have the selected version based on the executing JDK, but that may not be what you desire. The selection mechanism sounds better (just have them pick JDK 1.4 or 1.5, defaulting to one or the other, you can still list the dependencies normally).

After some discussions on the testng list it looks like the easiest solution may be to use the already existing classloader include logic in the booter, which I have done, to optionally include the right version of testng to include depending on the running jvm version. This has worked so far.

I'll update the issue more when I get closer to a final patch-worthy solution. (Should be early next week, I have to sync up with testng to get them patched and uploaded onto ibiblio as well).

I think that the majority of work is done now, besides a lot of weird reporting behaviour. Such as lots of assumptions about the xml output format, I mean it's getting substring index errors because it's hidden a sub "meta format" of "class <classname>" into the suite name attribute. Grrrr :/

Does this mean I need to submit a patch to codehaus as well? I think that will be 4 different project patches total to somehow get done all at once, what do I even do to get everyone on my version so they can test my results? I was thinking about trying to get testng to commit my changes and release to ibiblio first and then submit them all here afterwards. ..

Hey Brett, do you have any issues with me changing this so that reports are generated even with test failures? All of my experience with these things so far seems to indicate that _not generating a report should be the exception to the rule that requires additional properties to be set, but that always generating reports would definitely be the desired behaviour for the majority of people.

I'm going to add this in while I'm at it, unless someone says otherwise.

regarding changes - worry about the surefire-report-plugin later. It needs some work regardless.

is there a reason you need to change the xml format output? can it be done just by adding so existing stuff doesn't break?

The reason why the reporting plugin needed work was because he really needed a better grouping construct. Class names and package names were being parsed out of attributes in a very unintuitive way, but I've already made all the code changes to the report plugin as well, just one tiny little javascript change to the output and I'll be done. Either way I'll post all of my patches to everyone tomorrow morning (e.s.t.)

It was currently doing things like this in the xml output that was causing string index errors(while looking for class keyword):

<testsuite name="class org.foo.blah.ClassUnderTest" >

<test name="fooMethod" />

</testsuite>

Which I've changed to something more universally doable in junit & testng:

<testsuite name="ClassUnderTest" group="org.foo.blah">

</testsuite>

I think the change was needed whether testng came into the picture or not, but if people don't like it there may be other options, I was just getting runtime errors or else I might've tried to avoid doing anything at all.

the only disadvantage I see is that some of the xslt's that have been developed for the standard junit xml report format might no longer work. We should take that into consideration, but I don't see it as esssential.

Ahh, I didn't know about this part. The runtime errors are the biggest reason I did it, but perhaps there is an easy solution to the other dependencies. I have no idea.

I sent the testng group my patch a few minutes ago, when I get some approval (or make modifications + approval to get it into a commitable state) I'll post the patches here for all the surefire bits along with the jars you'll need on ibiblio to make it work. I'll submit the report plugin patch to the othe jira ticket and link these two tickets together. (If that's possible from completely different jira's. )

These patches should be enough for someone to play around with the patch work. I'm going to create sub-tasks on this issue for the work I still have left to do.

I still need to convert testng to use maven, at least for publishing to testng but thought I'd save myself the trouble if everyone hates the patches.

Thanks Jesse! I will be travelling for the next couple of weeks, and am not a test ng user. I'd suggest bringing this up further on the dev@ list once you are happy with the work. Don't be afraid to ask a couple of times if it takes a bit of time to get a response. I'm looking forward to trying this out later on.

The testng jars unfortunately don't live in ibiblio right now (will start happening once these patches get resolved), but the commands I've been using to install it into the local maven repo are:

mvn install:install-file -DartifactId=testng-jdk15 -DgroupId=testng -Dversion=4.4.5 -Dpackaging=jar -Dfile=testng-4.4.5-jdk15.jar
mvn install:install-file -DartifactId=testng-jdk14 -DgroupId=testng -Dversion=4.4.5 -Dpackaging=jar -Dfile=testng-4.4.5-jdk14.jar

IMPORTANT!!! ----------------------------------------
I had to modify my MAVEN_OPTS environment variable in order to get my jvm to read annotations by default. I don't know if there is a better workaround for this currently, I hope so as that would be a huge annoyance for users. I don't mind tackling that part as well, one thing at a time...

My MAVEN_OPTS looks like:
export MAVEN_OPTS="-ea"

The previous surefire-patch.txt is missing a new Java class (TestNGBattery) , the eclipse-subclipse extension I'm using didn't add unversioned resources automatically for me.

I don't have permissions to delete the previous patch upload or I would.

Yet another surefire patch

Hi Jesse,

Finally, I successfully applied the patch and everything compiled fine except the surefire-report-maven-plugin. See below.
Once I 'deactvated' the SurefireREportParserTest test, the report plug-in was compiled and installed successfully, though.

So far I did only some very quick testing - The good news is that 2 simple TestNG tests I have run, worked fine.

-------------------------------------------------------
T E S T S
-------------------------------------------------------
Fast test
Slow test
[surefire] Running Command line test
[surefire] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.031 sec

===============================================
Suite for Command line test
Total tests run: 2, Failures: 0, Skips: 0
===============================================

However, some of my 'real' tests failed (Exceptions). I will need to look at those a little bit closer later tonight.

Also, are there any further settings I have to make in my POM regarding TestNG's configuration? Or is everything the same as the typical settings you make for JUnit (include/exclude tests, skip tests etc.)?

In my test output I see the following output that is a bit irritating:

[surefire] Running Command line test (What does that mean??)

+++++++++++++++++++++++++++++++++++

As mentioned above, the "surefire-report-maven-plugin" was not successfully built initially due to a failing test.

[ERROR] BUILD ERROR
[INFO] ----------------------------------------------------------------------------
[INFO] There are some test failure.
[INFO] ----------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: There are some test failure.
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:555)

at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecut
or.java:472)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleEx
ecutor.java:303)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.ja
va:270)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
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:585)
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)
Caused by: org.apache.maven.plugin.MojoExecutionException: There are some test failure.
at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:401)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530)

... 16 more
[INFO] ----------------------------------------------------------------------------
[INFO] Total time: 7 seconds
[INFO] Finished at: Sat Jan 14 13:50:29 EST 2006
[INFO] Final Memory: 5M/11M
[INFO] ----------------------------------------------------------------------------

============================================================

org.codehaus.mojo.surefire.SurefireReportParserTest.txt contains:

-------------------------------------------------------------------------------
Battery: org.codehaus.mojo.surefire.SurefireReportParserTest
-------------------------------------------------------------------------------
Tests run: 6, Failures: 1, Errors: 0, Time elapsed: 0.094 sec

testParseXMLReportFiles(org.codehaus.mojo.surefire.SurefireReportParserTest) Time elapsed: 0.062 sec <<< FAILURE!

[ stdout ] ---------------------------------------------------------------

suite name CircleTest has group com.shape
suite name PointTest has group com.shape

[ stderr ] ---------------------------------------------------------------

[ stacktrace ] -----------------------------------------------------------

junit.framework.AssertionFailedError: expected:<2> but was:<3>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:201)
at junit.framework.Assert.assertEquals(Assert.java:207)
at org.codehaus.mojo.surefire.SurefireReportParserTest.testParseXMLReportFiles(SurefireReportParserTest.java:59)
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:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
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:585)
at org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:242)
at org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.java:216)
at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:303)
at org.apache.maven.surefire.Surefire.run(Surefire.java:227)
at org.apache.maven.surefire.Surefire.run(Surefire.java:102)
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:585)
at org.apache.maven.surefire.SurefireBooter.runTestsInProcess(SurefireBooter.java:293)
at org.apache.maven.surefire.SurefireBooter.run(SurefireBooter.java:208)
at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:383)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
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:585)
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)

I hope this provides some quick initial feedback.

Hopefully more up to date patches of system. These should work. The exception report you were getting was the same I was getting locally until I did a fresh "mvn install" of the surefire base system.

Try doing that first and then running the report plugin tests again.

Gunnar,

In regard to the 3 vs 2 suite assertion, it really should be 3 suites found. It could be an indicator that the testng reports aren't running correctly if only 2 exist. What is your environment like? I'm running jre 1.5 as the default jvm with "-ea" specified in MAVEN_OPTS to enable assertions.

For the configuration semantics, like running a single test vs running this or that, I'm not sure how far this should be attempted to be taken. JUnit and TestNG are so very different when it comes to this. I've successfully gotten the includes/excludes working just fine but this doesn't enable all of the features in testng that I would personally like to use. Such as configuring "groups" to run at runtime, or using the thread specifiers, or running distributed tests, etc. ...

Is it really a horrible thing if we allow the specific configurations for testng or junit that don't necessarily overlap? I don't know. My gut tells me that this doesn't seem entirely bad, and I'm not seeing a lot of situations where people are thrown off because presumably they are very familiar with the testing framework of their choice, and at least enough of the configuration parameters overlap to get them started.

Hi Guys,

Just wondering how I should proceed here. I've still got a few pieces to the plugin to complete, but am hesitant to keep writing code if this patch doesn't feel right to everyone.

I don't remember how the rules for ASF committer access work on a per-project basis, but if it helps I'm already part of the ASF. Perhaps a temporary, or surefire-only committer access might make this easier for everyone? I know people are busy and such. Just a thought

Jesse,

The test org.codehaus.mojo.surefire.SurefireReportParserTest fails also on a second machine, too. (Running JDK 5.0 and Maven HEAD + your patches + "-ea option" + I cleaned my local repository)

Also, just FYI, I was having some difficulties applying you patch for maven-surefire-plugin/src/it/test2/src/test/java/SurefireTest2.java using TortoiseSVN - I had to do some manual tweaking but then it worked.

Nevertheless, my TestNG test cases run fine now and the surefire report looks good, too!! Actually, so far I have no complaints, except for the label "Running Command line test", which is a bit irritating.

In regards to specifying configuration settings I would also prefer allowing specific TestNG settings to be set, that may not exit for JUnit. In those areas where JUnit and TestNG overlap the configuration settings should be the same (if it makes sense...)

I hope you get your SCM access soon and that maybe somebody else gives this a shot as well. Can't wait to see this in a released version )

Thank you for being so patient and diligent Gunnar. I think the missing unit test was another brain fart of mine when using the subclipse eclipse plugin. I've since fixed that but wanted to go ahead and finish off the rest of the parameters and such before I upload another set of patches. Should be soon.

Hello Jesse,

Sounds good. When you post a new patch, can you maybe put a timestamp into the file name or zip it up? I fear it may get a bit confusing otherwise
THANKS A LOT! Please let me know if I can help with anything else.

Regards,

Gunnar

I have no idea hot to manage all of these patches. I'm not quite as used to patching as committing, hence all of my original mistakes. wtf do I do to differntiate them?

No need for thanks, ultimately I am helping myself. Nothing would be worse than the total runtime of junit v s testng tests to suffer throughn again.

Everything is completely finished "for real" this time, I just got called for dinner and such before I had time to generate a new set of patch files. I will upload them tomorrow when I make more sense again.

Thanks for all your work on this Jesse. I certainly want to find time to apply these.

When you get time, please file a zip of the code diffs/new files and point out which should be applied and which should not.

It would be great to create a MAVENUPLOAD request for the testng JARs and link it to this.

Arghh! I've been trying to create patches for the last half hour but think I've screwed some state up with subversion somehow. I have a new src/it/test3 directory that subversion says is already under version control, and yet it won't let me add it to the patch because of an error stating:

"diff --old /home/jkuhnert/projects/maven-surefire-plugin
Working copy not locked; this is probably a bug, please report
svn: Working copy '/home/jkuhnert/projects/maven-surefire-plugin/src/it/test3' is missing or not locked"

I've tried all the svn commands I could think of to fix it but am running out of ideas.

Ok, the attached maven-patches.tgz file should contain everything needed to finish off the rest of this patch work.

I had to manually include the entire maven-surefire-plugin directory as I couldn't find a reasonable way to resolve my svn issues, sorry for that.

The tgz file also contains the ibiblio jar bundles for testng, which will be published and a ticket opened for the upload as soon as someone from testng with access rights to do it pushes them out. (I'm sure it will be sometime today, if not tomorrow).

Another thing to keep in mind is that people may run into some chicken and egg issues building some of the plugins as the test code invoked to install them is changing I got around this by cleaning out my local cache for surefire/maven-surefire-plugin before trying to do a local install.

Also, the test5 directory for the maven-surefire-plugin is the only one that contains jdk14 javadoc annotation tests. It will compile fine if your default jvm is 1.5, but won't find any tests if you run with a 1.5 jvm.

Lastly, I've been adding a lot of parameters for the SurefireBooter - > Surefire invocation. I'm sure Jason will be very mad at some of the code messyness (or, need for the surefire core to be refactored to account for some of the changes). I don't mind at all doing these refactorings, it would just be nice if they wouldn't require any delays in getting some of this code released so that people can start using testng with maven.

P.S. I woudln't mind at all if someone created a maven-surefire-testng-plugin (or similar) jira project/category that had my email as the default owner to handle any issues that come up in the field.

P.P.S I would also like to add some more documentation to the site xdocs/apt files so that testng.org can point a url at the appropriate place on maven.apache.org to users wanting to know how to use maven2 with testng..Guess that can be another round of patches

Let me know if anyone runs into any problems. I _haven't provided support for browsers with javascript disabled yet either. I think it would require creating a seperate .html page for each exception reported to make the links work with/without javascript. This can be done as well, just a bit much for me to take on right now without completely abandoning my other committments.

While the TestNG jars are now in the official Maven repository, the patches don't use them. I believe the TestNG jars itself are not correctly setup in the repository.

They are under:

org/testng/testng/4.4.7/

With the following settings:

<project>
<modelVersion>4.0.0</modelVersion>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>4.4.7</version>
</project>

But instead testng-4.4.7.jar there are 2 jars:

testng-4.4.7-jdk15.jar
testng-4.4.7-jdk14.jar

Shouldn't there be 2 deployments in the repository instead with the following settings: (??)

org/testng/testng-jdk15/4.4.7
org/testng/testng-jdk14/4.4.7

<groupId>org.testng</groupId>
<artifactId>testng-jdk14</artifactId>
<version>4.4.7</version>

and

<groupId>org.testng</groupId>
<artifactId>testng-jdk15</artifactId>
<version>4.4.7</version>

Hmmm Well yes, that is how I thought I had packaged them. I must have done somthing wrong with my mvn-upload request. This doesn't look right at all. I will post a new mvn-upload ticket today in hopes of resolving this.

Hi Jesse,

I applied the patches without major issues (although I got some really strange error messages first...after cleaning my local repository everything worked just fine...)

Anyway, I just ran a simple test and ran into a dependency issue. After some digging through the issue, it seems that the testng-jdk15-4.4.7.jar is not complete. The older version 4.4.5 you provided had some dependencies to qdox and bsh that were provided within the testng jar. 4.4.7 does not contain those dependencies anymore.

Thus when I run my test with your 4.4.7 jar I get the following error:

-------------------------------------------------------
T E S T S
-------------------------------------------------------

===============================================
Suite for TestNG Suite
Total tests run: 0, Failures: 0, Skips: 0
===============================================

java.lang.NoClassDefFoundError: com/thoughtworks/qdox/model/AbstractInheritableJavaEntity
at org.testng.internal.annotations.AnnotationConfiguration.<init>(AnnotationConfiguration.java:15)
at org.testng.internal.annotations.AnnotationConfiguration.<clinit>(AnnotationConfiguration.java:18)
at org.testng.SuiteRunner.getAnnotationFinder(SuiteRunner.java:314)
at org.testng.SuiteRunner$DefaultTestRunnerFactory.newTestRunner(SuiteRunner.java:345)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:177)
at org.testng.SuiteRunner.run(SuiteRunner.java:144)
at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:576)
at org.testng.TestNG.runSuitesLocally(TestNG.java:539)
at org.apache.maven.surefire.Surefire.run(Surefire.java:236)
at org.apache.maven.surefire.Surefire.run(Surefire.java:128)
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:585)
at org.apache.maven.surefire.SurefireBooter.runTestsInProcess(SurefireBooter.java:345)
at org.apache.maven.surefire.SurefireBooter.run(SurefireBooter.java:258)
at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:477)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:432)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:530)

at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecut
or.java:472)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleEx
ecutor.java:303)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.ja
va:270)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
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:585)
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)
RUN ABORTED
java.lang.NoClassDefFoundError
org.apache.maven.surefire.Runner
An exception or error caused a run to abort.
com/thoughtworks/qdox/model/AbstractInheritableJavaEntity

I had to add the following dependencies manually to my pom:

<dependency>
<groupId>qdox</groupId>
<artifactId>qdox</artifactId>
<version>1.5</version>
<scope>compile</scope>
</dependency>

<dependency>
<groupId>bsh</groupId>
<artifactId>bsh</artifactId>
<version>2.0b1</version>
<scope>compile</scope>
</dependency>

Afterwards everything worked fine. Thus, either testng needs to define those additional dependencies in its pom or they should be included into the testng jar file.

Hopefully, I will find some more time tomorrow to dig further into using TestNG with M2 - depending on how things go I can put my findings into a document, which might serve as a documentation skeleton

Sorry about the bad ibiblio upload again, don't know how I managed to do that but I re-opened the upload request with what I believe was the intended ibiblio files attached directly.

As for the documentation, I have added a small amount to testng's docs directly as well, but it would be nice to have the core maven xdoc/apt documentation updated

The testng community is feeling very sad from not having maven 2. :'(

test project: tacos.sf.net

I have applied this locally, and am committing to a branch

issues still to resolve:

• it won't work without a testNG dependency at present, breaking most junit tests. Separating the providers will help this.
• need more testing on jdk 1.4. It seems to work if I set source/target on the surefire pom
• code needs to be reformatted.