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
