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
