So, here's my thinking.
Runtime frameworks (xstream, sitemesh, objenesis, ...)* are governed by
what operations people are prepared to support in a production
environment. This usually means they are several JRE versions behind,
because ops people are notoriously conservative about upgrading things.
Development frameworks (jmock, hamcrest, ...)* can be more adventurous
because they don't have an impact on the production environment, just
the developer setup. JBehave falls into this latter category, so I'm
less worried about having it depend on Java 5.
We could do this in stages as Mauro suggests, by having some extensions
that use (and require) java 5 and others - and the core - that are still
1.4 compliant. Or we can bite the bullet - given that jbehave currently
has a relatively small user base (I'm assuming here, based on the list
traffic) - and move to 1.5. This would give us an opportunity to review
the codebase and see where generics and annotations might help make
jbehave more expressive.
Plus we get hamcrest for free.
What do you guys think? (Subject of course to consulting with that user
base :)
Cheers,
Dan
* That bloody Joe Walnes gets everywhere.
Elizabeth Keogh wrote:
Hi Jeff, Dan,
The breaking up of matchers is already done; I haven't started
including Hamcrest yet.
I love working with JBehave in Java 5, and would love it even more if
it used, internally, some of the amazingness that Java 5 provides. It
seems to me that our user base is (entirely?) made up of Java 5 users.
It would make the matchers much simpler, too.
Give me the word and I'll shift it over... :)
Cheers,
Liz.
"Jeff Grigg" <[EMAIL PROTECTED]> wrote on 24/07/2007 02:20:21:
> This strikes me as a really good idea: Making the Matcher creation
methods
> static for Java 5 and external access, and splitting them into multiple
> classes. One could still provide convenient Java 1.4 access by having
> UsingMatchers methods that forward to all the *Matchers classes.
>
> (I'm currently working towards introducing JBehave as a BDD tool in
several
> project heavily into JUnit usage. So I want to be able to use JBehave
> assertion logic from JUnit tests. I'm currently doing this with a
class I
> wrote, "public abstract class UsingMatchersTestCase extends
TestCase" that
> contains all UsingMatchers method signatures, and forwards all calls
to a
> local instance of UsingMatchers. It's working pretty well for me.
...at
> least so far. ;-)
> -- JeffGrigg
>
>
> ----- Original Message -----
> From: "Dan North" <[EMAIL PROTECTED]>
> To: <[email protected]>
> Sent: Wednesday, April 18, 2007 8:33 AM
> Subject: Re: [jbehave-dev] Re: Splitting UsingMatchers
>
>
> > [...]
> >
> > fwiw I agree about breaking out the matchers and making them
> > statically-importable. Maybe now is the time to start looking at
hamcrest
> > compatibility, and having the wider conversation about how we can
leverage
> > the java 5 features in a gracefully-degrading way.
>
> > --- Mauro Talevi wrote:
> >> +1.
> >>
> >> Perhaps we could also make the methods static. That way, folks
on JDK1.5
> >> can use static imports and not have to extends UsingMatchers,
while folks
> >> on JDK1.4 can keep on doing as before.
> >> Also, if static the split matchers can be invoked directly rather
than
> >> via the facade of UsingMatchers.
> >>
> >> Cheers
>
> >> Elizabeth Keogh wrote:
> >>>
> >>> Hi all,
> >>>
> >>> I'm trying to add Collection and Array matchers to UsingMatchers.
> >>>
> >>> This is now a really, really big class!
> >>>
> >>> I'd like to split it up and delegate to the package-accessible
splits,
> >>> because this will make it easier to maintain.
> >>>
> >>> The split I envisage at the moment is:
> >>>
> >>> CustomMatcher (move to top level)
> >>> UsingEqualityMatchers (eq, isNull, isA)
> >>> UsingCollectionMatchers (collectionContaining)
> >>> UsingArrayMatchers (arrayContaining)
> >>> UsingLogicalMatchers (and, or)
> >>> UsingStringMatchers (contains, startsWith, endsWith)
> >>> UsingExceptions (pending, fail, todo, runAndCatch)
> >>> Ensure (ensureThat)
> >>>
> >>> I think this will also be far easier to extend than what we have
now,
> >>> even if we do end up rewriting Hamcrest.
> >>>
> >>> I have also added the describe(Object arg) method to CustomMatcher,
> >>> which returns arg.toString() by default. This allows me to do neat
> >>> things like "Expected a collection containing <4> but got an
ArrayList
> >>> [5, 6, 7]".
> >>>
> >>> What do you think?
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>
