Bringing discussion to the list: Stefan Hübner (JIRA) wrote:
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.
I personally see behaviours as more along the lines of acceptance testing than unit testing. So rather than a replacement for JUnit, I would see it a replacement for Fit.
That said, some people might want to use BDD as a replacement for TDD. I would aim to find a configurable way to support both paradigms.
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.
I still need to convince myself of the best approach in this regard. I don't see "hyper-isolation" in classloading as necessarily a significant advantage - especially if offset against other cons or complications. The current approach is quite simple and configurable - it takes the libs configured in a given maven scope and builds a classloader with them. I'll give it more thought.
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.
Sure - and I appreciate your help greatly. I've been snowed under of late, but I'm aiming to get some work done (have some other patches to apply) and get out a 1.1 release soon.
Cheers --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
