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 lot and rely on it heavily.)
Stefan
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
