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: In JUnit
(and/or JBehave self-test?) and/or production JBehave code (as used by
your customers), one could scan the CLASSPATH to find behavior class
files. As a test, one could compare the list of class files found to
the list returned by the appropriate AllBehaviors class.
Does this interest you?
Should I say more?
Should I write code?
/Thank you for considering my suggestion./
/ - jeff/
----- Original Message -----
*From:* Elizabeth Keogh <mailto:[EMAIL PROTECTED]>
*To:* [email protected] <mailto:[email protected]>
*Sent:* Thursday, March 08, 2007 11:26 AM
*Subject:* [jbehave-dev] Now we have a stable release... using Ant
tasks for the build
One of the biggest problems I found while finishing off the 1.0
release was the occasional behaviour which had failed to get into
an AllBehaviours class. In every instance I found, the behaviour
was broken (and I wonder how many I haven't found!)
I would very much like to get rid of the AllBehaviours. They're
great, but not maintainable. This is going to become more of a
problem as the code base grows. I think there's far less risk of
the Ant tasks breaking and us not noticing than of us forgetting
to add a new Behaviour to a build file.
Please can I make the Build use JBehave's own Ant tasks to run
Behaviours as a file set?
Cheers,
Liz.
--
Elizabeth Keogh
[EMAIL PROTECTED]
http://www.livejournal.com/users/sirenian
