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