[jbehave-dev] Re: Maven 2 support
Stefan, sorry for the long wait - getting back to jBehaving ... Stefan Hübner wrote: So this would boil down to placing behaviours/stories either in src/main/java or src/test/java and scoping jbehave either in compile or test scope. The switch could be easily supported by a simple boolean configuration option, I guess. The plugin then would create a classloader upon either compile scope or test scope classpath elements. http://jira.codehaus.org/browse/JBEHAVE-90 - will be implemented shortly. 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. IMO the scenarios are a slightly different - in that surefire is an integrator of completely different projects, while the jbehave plugin is an extension module of the core. In this sense I'm not sure that the added complication is justified. Let's see if there is a usecase arises that justified the change - eg a bug or a problem of sorts. 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. That's my aim too :-) I've just applied the patches from Eric Lewin and I've deploy a snapshot release. I'd like to get out a 1.1 quite soon. Since we're talking about Maven2 support, may I also suggest to update jbehave's parent- and core-poms? The dependencies should be mentioned properly. This would help developers great deals. Can you please raise a jira issue? Thanks - To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
Re: [jbehave-dev] Re: Maven 2 support
Dan, thank you for statements and sorry for the delay. you wrote: Hi Stefan. Excuse me for wading in halfway through. I just want to add a couple of observations or suggestions. Firstly, as I have been doing more and more bdd-style projects, I have evolved into the following code structure: - app [the application] - src - resources ... - behaviour - stories [all the story/scenario/given/when/then classes] - src - resources ... - examples [all the object behaviour classes] - src - resources ... - integration [examples that use real services, like databases] - src - resources ... This directory structure is quite nice - as long as you use ant to handle the build process. With Maven you might want to separate the code into three modules like they call it. I will try to describe how I would structure your example to best suite maven. Think of a module as all the code that makes a JAR. A module also may contain some test code that won't make it into the JAR. A module looks like this: -src/ -main/ -java/ (this is where your app classes are) -resources/ (this is where your properties-files are) -test -java (this is where your test code is) -resources (this is where properties-files necessary for testing are) -pom.xml (the maven project descriptor) Also a module A can refer to another module B by making itself depend upon the other one. Maven then puts B on the classpath while compiling A. B is called a dependency of A. Maven also knows the concept of dependency scopes. you might put B into test scope when it's only needed while compiling and running the unit tests of A. This is especially useful when considering transitive dependencies which maven heavily relies on. Coming back to your example, Dan, your app code would go to an app module. There won't be any behaviours or stories in it. your example-behaviours would go to a second module I'll call app-behaviours. It depends on app. A third module app-stories would depend up on app and app-behaviours and eventually a forth app-integration would depend up on app and contains your integration tests. That is just the way I would structure it. Now, one more thing, you might want to do is to put all those modules into the same directory and define a so called multiproject pom which refers to all those modules as submodules of itself. When running maven on this structure, it compiles them knowing which are to be build before others. And it runs their behaviours, provided the jbehave-plugin is configured properly in app-behaviours, app-stories and app-integration. Mauro, you might have a different view point? I used to think there was a continuum between describing object interactions (traditional TDD plus mocking) and describing application behaviour (stories and scenarios) but I've since concluded that there are (at least) two discrete levels, hence the directory structure. (There is probably another one above this for interactions across multiple system boundaries, but enterprise BDD is still a little way off - I'm working on it!). I'm trying to come round to Brian Marick's term of exemplars rather than examples because it is more correct, but it just sounds odd to me. My build starts by compiling up the app classes (sometimes into a jar), then compiles and runs the example classes with the app classes on the classpath, then compiles and runs the story classes with both the examples and app classes on the classpath. This three-stage approach means I know my app doesn't have any dependencies on any supporting code, and that my story behaviours can reuse code from my example behaviours (say, Builders or other helper classes). It also means my app classes are ready to be bundled up and deployed. The maven module structure described above should work just like described it. I have found that this is easy using ant (sorry, I'm not a maven user) with the added benefit that it doesn't require any classpath mojo from jbehave itself. I would prefer to keep the classpath magic as simple as possible in jbehave, so I'd need to see a compelling reason to change Mauro's existing solution (other than tidying it up - have you seen the code Mauro writes?)* No question there! I feel like I should explain the history of my original patch. I tried to use the maven plugin for a project and couldn't get it running. I tried it on the hellbounds examples and couldn't make it running. So I had a look into the code and compared it to the way other plugins execute code. I'm not a maven expert though, so I perhaps have failed to identify the actual reason the plugin failed. My patch wasn't to make the plugin nicer or wipe out code that did work. It didn't and I just tried to find a way to make it work. Cheers, Dan * For the record: Mauro writes some pretty good code :) I've no doubt about this :-) (I use jmock a
[jbehave-dev] Re: Maven 2 support
Stefan Hübner wrote: So this would boil down to placing behaviours/stories either in src/main/java or src/test/java and scoping jbehave either in compile or test scope. The switch could be easily supported by a simple boolean configuration option, I guess. The plugin then would create a classloader upon either compile scope or test scope classpath elements. Yep - and that can be accomplished with current impl, I believe. All that matters is to make the classpath elements javadoc property settable via the pom. 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. Fine. I'll those two classloader approaches a try in different scenarios. Fine - let's evaluate pros and cons. Since we're talking about Maven2 support, may I also suggest to update jbehave's parent- and core-poms? The dependencies should be mentioned properly. This would help developers great deals. The parent has no dependencies. The core deps will be added - you're right. Cheers - To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
Re: [jbehave-dev] Re: Maven 2 support
Hi, Mauro wrote: Bringing discussion to the list: [SNIP] 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. So this would boil down to placing behaviours/stories either in src/main/java or src/test/java and scoping jbehave either in compile or test scope. The switch could be easily supported by a simple boolean configuration option, I guess. The plugin then would create a classloader upon either compile scope or test scope classpath elements. 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. Fine. I'll those two classloader approaches a try in different scenarios. 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. Since we're talking about Maven2 support, may I also suggest to update jbehave's parent- and core-poms? The dependencies should be mentioned properly. This would help developers great deals. Cheers - To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
