That is a great idea. What about:
new BeahviourLoader().loadBehavioursUnderPackage(AMarkerClass.class.getPackage()) On 12/1/06, Dan North <[EMAIL PROTECTED]> wrote:
No worries. Sorry I came across a bit snappy. It's just that I spent a bunch of time today chasing my tail trying to find out why random behaviours were running! I agree it would be useful to have an abstraction that said "all behaviours in this package and below" - I'm just not sure how best it should be expressed. Cheers, Dan Shane Duan wrote: > Hi Dan, > > I think I understand your argument. I did that in my first XP project > when JUnit library is all that you have. And I remember going through > some pain because of that list. It has been so long since I have not > had an automated way of collecting the tests so I really don't > remember what the problem was. > > For now, I think we just need to watch out to see which way turns out > to be less painful. > > The duplication is probably because they are all compiled into the > same directory. > > Cheers > Shane > > On 12/1/06, Dan North <[EMAIL PROTECTED]> wrote: >> Hi Shane. >> >> I want to find out why the extensions.threaded.swing behaviours were >> being run before we change the AllBehaviours back to using a >> BehavioursLoader. Also, the build now takes 13 seconds on my machine >> rather than 30, so there was definitely some duplication happening. >> >> I've found that the AllBehaviours were easy enough to maintain because >> in general you are only adding one new Behaviour class at a time. >> >> Cheers, >> Dan >> >> Shane Duan wrote: >> > Hi Dan, >> > >> > That change was mine, done several month ago. >> > >> > I think jbehave.AllBehaviours should be reverted to include all other >> > AllBehaviours individually but are you sure you want to hard wire all >> > other AllBehaviours one by one? It would be a nightmare to maintain >> > that list. >> > >> > Hope this makes sense. >> > >> > Regards, >> > Shane >> > >> > On 12/1/06, Dan North <[EMAIL PROTECTED]> wrote: >> >> >> >> Hi folks. >> >> >> >> I'm finding I can't run isolated sets of behaviours, due to the >> sudden >> >> proliferation of some magic code, namely: >> >> >> >> return new >> >> BehavioursLoader(getClass()).loadBehaviours(); >> >> >> >> This magic is a lot less expressive than listing the behaviours >> in each >> >> extension (especially since many of them only have one behaviour >> class). >> >> >> >> I was trying to run jbehave.AllBehaviours, which contains these: >> >> >> >> jbehave.core.AllBehaviours.class, >> >> jbehave.ant.AllBehaviours.class, >> >> jbehave.jmock.AllBehaviours.class, >> >> jbehave.junit.AllBehaviours.class, >> >> jbehave.core.story.AllBehaviours.class >> >> >> >> However, I was getting failures from >> >> jbehave.extensions.threaded.swing. Not good (the fact it >> >> was running at all, not the errors). >> >> >> >> So, I've reverted the above AllBehaviours classes to hard-wired >> >> behaviours. >> >> >> >> I noticed in reverting them that the build now runs the same 168 >> >> behaviours >> >> twice, so this magic was also masking a duplication in the build.xml. >> >> >> >> Please, in future, do not make changes like this without asking >> first. >> >> >> >> Thanks, >> >> Dan >> >> >> >> >> > >> > >> >> >> --------------------------------------------------------------------- >> 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
-- Shane http://www.shaneduan.com --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
