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
