Maven 2 support

Dear Mauro and JBehave team,

please find attached patch with a proposed fix for BehaviourRunnerMojo's classloader issue. It works by completly isolating into an classloader the BehaviourRunner and the behaviours to be verified. That classloader only knows a project's target/classes, target/test-classes and its dependencies of scope "test".

Hope this helps you, as it helped me.

Cheers
Stefan

PS: Also, I was working on extending your mojos to accept include/exlude patterns for searching for Behaviour-/Story-classes. That way JBehave's ant tasks and maven plugin would provide similar options to the user regarding the selection of classes (at least, in the beginning I was confused with those slight differences).
If you're interested, please let me know. I'd be happy to contribute the code.

Stefan, a few comments from a cursory look.

I have purposefully avoided linking the behaviour scope to 'test'.
Also, I'm not sure I understand how this proposed patch differs from current implementation. It too uses a separate classloader to instantiate the behaviours.

I'll have a look into more detail during the week. Thanks.

Mauro,

Stefan, a few comments from a cursory look. I have purposefully avoided linking the behaviour scope to 'test'.

Oh, maybe I should have asked before altering the plugin to serve my personal needs. I was assuming, that behaviours are - in a way - like unit tests. So I put them into the src/test/java-folder instinctively. Now I know, my perception was misled maybe.

But to stretch that thought a bit - by assuming the behaviours are to be found in src/main/java you seem to recommend a multiproject structure, where behaviours or stories are placed in parallel modules of the one to be verified. So e.g. I have a modul "A" for what I like to write some specs. I would end up with a multiproject structure comprising a second modul "A-behaviours" and a third "A-stories". Or maybe just two, like "A" and "A-specs"-modules glued together by an aggregating multiproject-POM. Is this what you suggest? I could happily live with that. Should have known just a bit earlier.

Also, I'm not sure I understand how this proposed patch differs from current implementation. It too uses a separate classloader to instantiate the behaviours.

I took the approach the surefire-plugin is based on. It doesn't import any JUnit-specific classes, but instead loads them into a completely isolated classloader. Of course this brings some nasty reflection mechanics as a side effect, though.

The difference to your implementation is, that the patched plugin doesn't leave the classloading hassles to the jbehave-library. Rather it puts the jbehave-classes into the same classloader, that serves as the classloader for the behaviours to be verified. So jbehave is on the same classpath as the behaviours and nowhere else.

I did some experiments with the hellbound example, put it's sources into different modules and tried to run the behaviours. The patch worked fine. So I was happy with it and thought, you'd find it handy too.

But either way, I'd just like to see a maven plugin that works, since I appreciate your effort very much. I do hope seeing the project gaining momentum in the near future. To me, a maven plugin is a must though, before I can spread the word.

Stefan, these are valid points, worth discussing. Bringing it to dev list.

Closing this issue as Maven 2 support has been implemented.

Any further improvements should be dealt with by separate specific issues.