If we've already solved it there's no point reinventing the wheel. As
long as it's jbehave code and we don't re-introduce the dependency on
cotta, then I say yes.
Shane Duan wrote:
Hi,
Sorry it took me a while to catch up with the code base.
There was a class, BehavioursLoader, that can take a class as the
input parameter, finds the classpath entry that contains that class,
and load all the behavior classes in that entry. That was the whole
reason that cotto existed in jbehave
Looks like that is gone, and we are discussing this issue.
Would this be a good time to bring back the code?
Cheers
Shane
On 3/9/07, Jeff Grigg <[EMAIL PROTECTED]> wrote:
I posted this email thread as a comment on Core issue #45, "Behaviour
discovery and collecting":
http://jira.codehaus.org/browse/JBEHAVE-45
Original jira ticket description is: "There should be a way to
automatically discover all the behaviours and run them as part of the
core
system to ease the IDE and ANT support"
----- Original Message -----
From: Dan North
To: [email protected]
Sent: Friday, March 09, 2007 8:12 AM
Subject: Re: [jbehave-dev] Now we have a stable release... using Ant
tasks
for the build
I like both of those.
I think it should be up to the developer whether they choose an
opt-in or an
opt-out model, but having a sanity checker that showed any behaviour
classes
that weren't in an AllBehaviours class, maybe as a warning during the
build,
would rock. As would something that found behaviours in (an arbitrary
list
of) directories, which could be the classpath, perhaps.
Can you post a Jira ticket for it please?
Cheers,
Dan
Jeff Grigg wrote:
Sounds like a problem that could be solved with reflection: [...]
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
