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.
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.