replace test plugin with surefire

I recently posted to the Maven Users list, stating that I was going to work on the Jelly maven-test-plugin and attempt to allow all of the user visible properties to be set, rather than to have some be linked directly to properties in the POM.

Brett responded that such were the goals of the surefire plugin. I see in this entry that the surefire integration is scheduled for 1.1-beta-2, but, and I hope that you'll forgive me, I haven't been able to figure out when that release is scheduled to take place. Given that I don't want to take on a task that is likely to be superceeded quickly after its release, would someone be willing to comment on the likely date of the beta-2 release and the likelihood that an integrated surefire plugin will be available in that release. Thanks.

no date on the 1.1-beta-2 as yet.

Basically, some things need to happen:
1) m2 surefire plugin gets up to feature level of m1 test plugin
2) m1 plugin rewritten to make sure of surefire plugin (or just surefire itself as the plugin probably only passes off the m2 project settings to surefire which is what the m1 version should do too)

We'd appreciate it if you were able to help with that effort instead of doing the work directly on the m1 plugin. I understand it would take longer, but it will be of much more long term benefit and would immediately help m2 users also

Brett,

I set out to figure out how to help with the surefire port rather than on the m1 test plugin. Unfortunately, I seem to be missing the information that I need to be useful, so if you could help me out....

I have checked out the Maven 1 code, and I see that there is the beginning of a plugin to call the M2 surefire plugin. I downloaded an m2 version from the svn repository. I learned that it depended on surefire code from Codehaus. I have an old cvs checkout of the Codehaus code, but it is out of date with the code in svn at Codehaus. I can't find the surefire svn repo at codehaus, can you give me a pointer? Is there any other information that you can point me to? Is there a list of M1 test plugin usecases and/or a list of m2 surefire usecases? I'm going to take a look at the how to build a plugin examples. Thanks for your response to my question about configuraing a plugin with includes and excludes.

Brett , Trygve & Emmanuel,

I took Trygve's suggestion and I grabbed the surefire code from codehaus svn. i grabbed the maven 2 code and built it 2 days ago, and Trtygve was right again, with the more recent code the surefire plugin worked properly WRT includes and excludes. I see that at codehaus there is a "Mojo" project, that Brett owns, and there is a surefire-report plugin there.

I guess that I'm asking for some direction here. I take it that the maven-1 surefire plugin ought to invoke surefire directly with the arguments that the surefire M2 plugin passes. Under what circumstances, if any, ought the M2 surefire report plugin be invoked by the m1 plugin?

If one of you would comment I would attempt to wire this up.

I'm not sure what the best way is, there are at least two solutions to this:

1) The easy way Add setters to the Mojo and use it as a normal bean in jelly. Then you will have to map the Maven 2 expressions to the Maven 1 $

object etc. This is possible as the MavenProject and ArtifactRepository actually doesn't seem to be used in the plugin at all. I'll look into removing those in the morning.

2) The more correct way: Create a infrastructure for embedding Maven 2 and get Maven to instanciate and execute the Mojo. This will require a way to map a Maven 1 project to a Maven 2 project and a lot of other stuff.

This is probably way more work than you're ready for and solution 1) will suffice for now.

In Brett's comment of 9 August above, he stated the that among the preconditions for going forward with the backport of the surefire plugin to M1 was that the "...m2 surefire plugin gets up to feature level of m1 test plugin ".

A naive survey of the situation might lead someone to believe that such an event might be a long way off, for 3 reasons:

1) the surefire plugin does not generate an XML for JUnit tests

2) a JUnit report contains in addition to the test case results, a whole list of properities and values from the underlying Ant environment, since M1 is executing the Ant JUnit task

3) the current surefire plugin works, andf there are plenty of things that don't work , so why invest core team energy where it isn't required to meet upcoming deliveries?

As an outsider with no coding assignments, and having volunteered to work on this, I've been looking at the surefire report package and at the Ant JUnit optional task package, and some sort of XML report of the test results shouldn't be too hard to come up with, but I have understood from the users list that there is no agreement on a candidate "properties set" that would be added to the XML report to provide a feature level match.

I'm sure that I've left out other features towards the feature level. If someone would be willing to enumerate them, I'd be willing to take a crack at adding them.

In Trygve's comment above of 23 August, he spoke about creating an infrastructure for embedding M2 into an M1 environment. Has anyone made any progress on that, and if so, where would I look to find the code?

One more question if you will, is there any reason why I shouldn't go ahead and rework the m1 test plugin and the m1 itest plugin by modifying the existing jelly code and either 1) refactoring some behavior or 2) simply exposing all of the necessary configurable parameters of the test plugin?

1) As you're saying this shouldn't be hard. Just add a new surefire reporter

2) I don't think that this is a really important feature, the Maven 1 plugin doesn't use it for anything in particular. And I'm pretty sure it's just a dump of System.getProperties()

3) Well, you asked for something to do

One major feature I know that's missing is the ability to fork the tests, which I see as the biggest issue to fix.

I haven't looked into making some infrastructure for embedding Maven 2 in Maven 1 yet but I don't think it's strictly needed for this plugin. I think that doing this plugin "by hand" might give a more clear overview over what's really needed.

Don't see why this should be a blocker.