btw, there seems to be still an issue with the classpaths. The freemarker generator doesn't find log4j (which is in the test classpath). It only works if I add log4j manually. Otherwise I get the following exception:
Caused by: org.jbehave.core.embedder.Embedder$RunningEmbeddablesFailed: Failure in running embeddable: at.mycustomer.jbehave.SVNRValidationStory at org.jbehave.core.embedder.Embedder.runAsEmbeddables(Embedder.java:132) at org.jbehave.mojo.RunTestStoriesAsEmbeddables.execute(RunTestStoriesAsEmbeddables.java:19) ... 21 more Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Priority at freemarker.log.Log4JLoggerFactory.getLogger(Log4JLoggerFactory.java:65) at freemarker.log.Logger.getLogger(Logger.java:284) at freemarker.template.utility.SecurityUtilities.<clinit>(SecurityUtilities.java:67) at freemarker.ext.beans.BeansWrapper.<clinit>(BeansWrapper.java:147) at freemarker.template.ObjectWrapper.<clinit>(ObjectWrapper.java:69) at freemarker.core.Configurable.<init>(Configurable.java:139) at freemarker.template.Configuration.<init>(Configuration.java:142) at freemarker.template.Configuration.<clinit>(Configuration.java:127) at org.jbehave.core.reporters.FreemarkerProcessor.configuration(FreemarkerProcessor.java:30) at org.jbehave.core.reporters.FreemarkerProcessor.process(FreemarkerProcessor.java:21) at org.jbehave.core.reporters.TemplateableViewGenerator.write(TemplateableViewGenerator.java:237) at org.jbehave.core.reporters.TemplateableViewGenerator.createReports(TemplateableViewGenerator.java:189) at org.jbehave.core.reporters.TemplateableViewGenerator.generateReportsView(TemplateableViewGenerator.java:111) at org.jbehave.core.embedder.Embedder.generateReportsView(Embedder.java:246) at org.jbehave.core.embedder.Embedder.generateReportsView(Embedder.java:234) at org.jbehave.core.embedder.Embedder.runStoriesAsPaths(Embedder.java:213) at org.jbehave.core.junit.JUnitStory.run(JUnitStory.java:24) at at.mycustomer.jbehave.StoryContainerBase.run(StoryContainerBase.java:80) at org.jbehave.core.embedder.Embedder.runAsEmbeddables(Embedder.java:123) ... 22 more Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Priority at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230) If this plugin needs log4j for logging, then you should add it to the plugin dependencies imo. LieGrue, strub ----- Original Message ----- > From: Mark Struberg <strub...@yahoo.de> > To: "dev@jbehave.codehaus.org" <dev@jbehave.codehaus.org> > Cc: > Sent: Friday, March 29, 2013 2:39 PM > Subject: Re: [jbehave-dev] JBEHAVE-454 ClassPath question > > counter indication is that you might get test mocks, test resource > definitions, > etc creeping in. > > Explicitely making it an own mojo is a safe bet. > For my project both ways would work, but for others it might not be > sufficient > to always get all the test classpath. > > LieGrue, > strub > > > > > ----- Original Message ----- >> From: Mauro Talevi <mauro.tal...@aquilonia.org> >> To: dev@jbehave.codehaus.org >> Cc: >> Sent: Friday, March 29, 2013 9:25 AM >> Subject: Re: [jbehave-dev] JBEHAVE-454 ClassPath question >> >> Actually, I would argue that having behaviour verification in a separate >> module in compile scope should be considered a better practice. >> >> Integration tests usually have cross-cutting concerns that span multiple >> Maven modules, whereas the tests in a module's src/test directory are >> meant to test the functionality of that module. >> >> But, regardless, having the resolution scope set to test will cater for >> both use cases. >> >> If the user decides to use the plugin in scope compile, this is included >> in the test one, and the only minor drawback possibly is that you'll > get >> a few extra test-scope dependencies pulled in the resolution, but given >> that JBehave is a testing tool and the Maven modules are usually the >> leaves of a build reactor I don't see counter-indications. >> >> Cheers >> >> On 28/03/2013 19:39, Mark Struberg wrote: >>> >>> Not sure if this is a good idea. There might be pure behave projects > which >> have their behave tests defined as compile scope in src/main/java. I guess >> it's not the standard case but might theoretically have happened. But > you >> know this part much better than I do. All I could do is to point you to the > >> implication of @requiresDependencyResolution, to define the expected usage > is >> your task ;) >>> >>> txs and LieGrue, >>> strub >>> >>> >>>> ________________________________ >>>> From: Mauro Talevi <mauro.tal...@aquilonia.org> >>>> To: dev@jbehave.codehaus.org >>>> Sent: Thursday, March 28, 2013 12:46 AM >>>> Subject: Re: [jbehave-dev] JBEHAVE-454 ClassPath question >>>> >>>> >>>> We could make all mojos use @requiresDependencyResolution test >>>> >>>> I don't see any counterindication atm. Let me think about it > ... >>>> >>>> Cheers >>>> >>>> On 26/03/2013 10:21, Mark Struberg wrote: >>>> >>>> hmm, maybe it got filtered out by the spam filter? I attached the >> git-format-patch output. LieGrue, >>> strub ----- Original Message ----- >>>>> From: Mauro Talevi <mauro.tal...@aquilonia.org> To: >> dev@jbehave.codehaus.org Cc: >>> Sent: Monday, March 25, 2013 11:07 PM >>> Subject: Re: [jbehave-dev] JBEHAVE-454 ClassPath question Where have > you >> sent the patch? On 25/03/2013 21:15, Mark Struberg wrote: >>>>>> Hi Mauro! Just sent a patch for git-am. The main > issue is >> that you need a >>> @requiresDependencyResolution test in the Mojo if if should also >> pickup test classpath entries. Otherwise you >>>>>> will only get the runtime classpath. >>>>>> txs and LieGrue, >>> strub ----- Original Message ----- >>>>>>> From: Mauro Talevi > <mauro.tal...@aquilonia.org> >> To: dev@jbehave.codehaus.org Cc: >>> Sent: Monday, March 25, 2013 12:36 AM >>> Subject: Re: [jbehave-dev] JBEHAVE-454 ClassPath question HI, > can >> you send us a simple mvn project reproducing the issue? The issue >>> JBEHAVE-454 should be closed AFAICS. You're issue could be >>>>>> related to >>>>>> something else. Cheers On 24/03/2013 20:01, Mark >> Struberg wrote: >>>>>>>> Hi folks! I have a question regarding >>>>>> http://jira.codehaus.org/browse/JBEHAVE-454 >>>>>> This issue is still marked as 'open' and I >> currently >>>>>> facing the >>>>>> same problem. >>>>>>>> I _do_ have <scope> set to test, but > still >> the jbehave >>>>>> story gets >>>>>> executed with the EmbedderClassLoader which does _not_ >> contain any test >>> classpath. >>>>>>>> My problem starts when I start a dependency >> injection container >>>>>>>> (OpenWebBeans, Spring, Weld or embedded TomEE) >> because they try to scan >>>>>> the >>>>>> ClassPath and subsequently fail to @Inject my beans. >>>>>>>> There is also a 2nd thingy, which is more a >> question kind of: for >>>>>> CDI I >>>>>> need to assign/open some Contexts to a new Thread. Is > there >> some hook >>>>>> where I >>>>>> can perform these tasks? I've seen the stories get >> executed >>>>>> asynchronously >>>>>> via Futures. >>>>>>>> Is there interest in cleaning this up, or is > even >> someone working >>>>>> on it >>>>>> atm? >>>>>>>> I could help a bit on the maven part if this > helps >> - though I >>>>>> might need >>>>>> some help on the jbehave side... >>>>>>>> txs and LieGrue, >>> strub >>>>>> >> --------------------------------------------------------------------- >>>>>> To unsubscribe from this list, please visit: >> http://xircles.codehaus.org/manage_email >>>>>>>> >> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >> http://xircles.codehaus.org/manage_email >>>>>>> >> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >> http://xircles.codehaus.org/manage_email >>>>>> >> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >> http://xircles.codehaus.org/manage_email >>>>>> >>>>>> >> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >> http://xircles.codehaus.org/manage_email >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
