Ah I see, txs 4 the pointer. LieGrue, strub
----- Original Message ----- > From: Mauro Talevi <mauro.tal...@aquilonia.org> > To: dev@jbehave.codehaus.org > Cc: > Sent: Friday, April 5, 2013 12:27 AM > Subject: Re: [jbehave-dev] JBEHAVE-454 ClassPath question > > Hi Mark, > > this is a known issue. Some dependencies need to be added to the > plugin configuration. > > http://jbehave.org/reference/stable/maven-goals.html > > Cheers > > On 31/03/2013 20:12, Mark Struberg wrote: >> 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 >> >> > > > --------------------------------------------------------------------- > 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
