> I'm not massively keen on your extension of AnnotatedEmbedderRunner, I was > purposely trying to avoid that, trying to avoid the "baggage" that comes > with the AnnotatedEmbedderRunner & BlockJunit4Runner, trying to avoid all > that complexity. There are the Filterable methods on ParentRunner, that just > don't affect the test run at the moment, for instance. I was trying to > simplify the whole thing tbh, which when coming at it fresh 2-3 weeks ago, > was a bit overly complex. It took me a 2-3 hours just to get JUnit to pick > up my tests correctly. > > > There may be a case for changing the runner impl, possibly on both. Let's > evaluate pros and cons. >
Cool. I was leaving the existing ones as-is, so it didn't break compatibility with any existing uses. > The @Configure annotation does very little when using Guice for instance, > except to ignore any classes from the Modules if it's not present. (This > confused me for a good 20mins until I stepped into the actual running code). > > > Sorry email jumped the gun ... The @configure tells the builder to build > the Configuration whether with Guice or other DI mechanism. > > Yeah, I think I misunderstood that a bit :) Had another look, and it makes a bit more sense now. > The reason for the Maven goal, was so it could use the @UsingPaths > annotation, which the way I had written the previous JUnit runner wasn't > possible using that, and (again) just to simplify it. My eventual plan was > to move some of the config from @UsingEmbedder into the POM and also to > potentially create a new workflow for Maven just for JBehave tests. We're > using JBehave for acceptance testing, so have our tests in a separate maven > module to the code it's actually testing. > > > The embedder controls are settable already in the pom via the existing > plugin goals. I'll work on making the examples clearer and separating exec > configuration in different modules. > > Ahh.. I will have another look into this then.
