JavaHamcrest 7.0
204 views
Skip to first unread message
Steve Freeman
Dec 22, 2014, 3:07:40 PM12/22/14
to hamcre...@googlegroups.com
Chatting briefly with Nat recently, it became clear that one blocker to change is the complexity of the current build. So I have a proposal, which I'll call Hamcrest 7.0. When we port to Java 8, it will become Hamcrest 8.0.
1) collapse everything to one jar. I can't think of a use case where all the different sub jars are useful.
2) Freeze the Matchers and CoreMatchers classes. As the number of matchers grows, the Matchers class is getting too large to be useful, and the code-gen step is a pain. I propose that we break up the collection matchers in ListMatchers, SetMatchers, etc, like the Google collections API does, which I believe will fix some of the template pain. Similarly for other types of matchers. It's not that much of a burden to write new helper factory methods by hand and modern IDEs will do the hard work of importing. Check in the current version of Matchers for backwards compatibility but deprecate it.
3) This allows us to port to Gradle as a build tool, which has some publishing features built in.
When all of this is stable, the clean up starts with Hamcrest 7.1
For Java 8 matching, as some have mentioned, we start an additional library where extra features become candidates for including in the next major release.
I've started a branch in GitHub.
Thoughts?
S
1) collapse everything to one jar. I can't think of a use case where all the different sub jars are useful.
2) Freeze the Matchers and CoreMatchers classes. As the number of matchers grows, the Matchers class is getting too large to be useful, and the code-gen step is a pain. I propose that we break up the collection matchers in ListMatchers, SetMatchers, etc, like the Google collections API does, which I believe will fix some of the template pain. Similarly for other types of matchers. It's not that much of a burden to write new helper factory methods by hand and modern IDEs will do the hard work of importing. Check in the current version of Matchers for backwards compatibility but deprecate it.
3) This allows us to port to Gradle as a build tool, which has some publishing features built in.
When all of this is stable, the clean up starts with Hamcrest 7.1
For Java 8 matching, as some have mentioned, we start an additional library where extra features become candidates for including in the next major release.
I've started a branch in GitHub.
Thoughts?
S
Colin Vipurs
Dec 23, 2014, 7:56:37 AM12/23/14
to hamcre...@googlegroups.com
That all sounds good to me.
One of the nice things about the Matchers/CoreMatchers classes is it makes discovery really easy, could something similar be done for the new classes, so instead of ListMatchers, SetMatchers etc., invert the naming, so something like MatchersForSets, MatchersForLists ?
If you need an extra pair of hands, I'm happy to contribute.
S
--
You received this message because you are subscribed to the Google Groups "Hamcrest Java Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hamcrest-jav...@googlegroups.com.
To post to this group, send email to hamcre...@googlegroups.com.
Visit this group at http://groups.google.com/group/hamcrest-java.
For more options, visit https://groups.google.com/d/optout.
Maybe she awoke to see the roommate's boyfriend swinging from the chandelier wearing a boar's head.
Something which you, I, and everyone else would call "Tuesday", of course.
Something which you, I, and everyone else would call "Tuesday", of course.
Nat Pryce
Dec 23, 2014, 9:14:01 AM12/23/14
to hamcre...@googlegroups.com
On 23 December 2014 at 12:56, Colin Vipurs <zodi...@gmail.com> wrote:
One of the nice things about the Matchers/CoreMatchers classes is it makes discovery really easy, could something similar be done for the new classes, so instead of ListMatchers, SetMatchers etc., invert the naming, so something like MatchersForSets, MatchersForLists ?
Good idea. Not sure of the naming -- it feels a bit verbose. Maybe MatchingSets, MatchingLists, ...?
Could you add the suggestion to https://github.com/hamcrest/JavaHamcrest/issues/85 so that we don't forget about it?
Thanks
Nat Pryce
Dec 23, 2014, 1:00:19 PM12/23/14
to hamcre...@googlegroups.com
On Tuesday, 23 December 2014 14:14:01 UTC, Nat Pryce wrote:
On 23 December 2014 at 12:56, Colin Vipurs <zodi...@gmail.com> wrote:One of the nice things about the Matchers/CoreMatchers classes is it makes discovery really easy, could something similar be done for the new classes, so instead of ListMatchers, SetMatchers etc., invert the naming, so something like MatchersForSets, MatchersForLists ?Good idea. Not sure of the naming -- it feels a bit verbose. Maybe MatchingSets, MatchingLists, ...?
Or maybe just MatchStrings, MatchLists, etc.
Where should allOf, anyOf and not go?
Could you add the suggestion to https://github.com/hamcrest/JavaHamcrest/issues/85 so that we don't forget about it?Thanks
If you need an extra pair of hands, I'm happy to contribute.
On Mon, Dec 22, 2014 at 8:07 PM, Steve Freeman <st...@m3p.co.uk> wrote:
Chatting briefly with Nat recently, it became clear that one blocker to change is the complexity of the current build. So I have a proposal, which I'll call Hamcrest 7.0. When we port to Java 8, it will become Hamcrest 8.0.
1) collapse everything to one jar. I can't think of a use case where all the different sub jars are useful.
2) Freeze the Matchers and CoreMatchers classes. As the number of matchers grows, the Matchers class is getting too large to be useful, and the code-gen step is a pain. I propose that we break up the collection matchers in ListMatchers, SetMatchers, etc, like the Google collections API does, which I believe will fix some of the template pain. Similarly for other types of matchers. It's not that much of a burden to write new helper factory methods by hand and modern IDEs will do the hard work of importing. Check in the current version of Matchers for backwards compatibility but deprecate it.
3) This allows us to port to Gradle as a build tool, which has some publishing features built in.
When all of this is stable, the clean up starts with Hamcrest 7.1
For Java 8 matching, as some have mentioned, we start an additional library where extra features become candidates for including in the next major release.
I've started a branch in GitHub.
Thoughts?
S
--
You received this message because you are subscribed to the Google Groups "Hamcrest Java Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hamcrest-java+unsubscribe@googlegroups.com.
To post to this group, send email to hamcre...@googlegroups.com.
Visit this group at http://groups.google.com/group/hamcrest-java.
For more options, visit https://groups.google.com/d/optout.
--Maybe she awoke to see the roommate's boyfriend swinging from the chandelier wearing a boar's head.
Something which you, I, and everyone else would call "Tuesday", of course.
--
You received this message because you are subscribed to the Google Groups "Hamcrest Java Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hamcrest-java+unsubscribe@googlegroups.com.
To post to this group, send email to hamcre...@googlegroups.com.
Visit this group at http://groups.google.com/group/hamcrest-java.
For more options, visit https://groups.google.com/d/optout.
Nat Pryce
Dec 23, 2014, 5:56:32 PM12/23/14
to hamcre...@googlegroups.com
I've pushed the start of an implementation of MatchStrings, etc. to the v7.0 branch. What do you think?
There's still a bit of work to be done cleaning up the once-generated code, applying deprecation comments, etc.
To unsubscribe from this group and stop receiving emails from it, send an email to hamcrest-jav...@googlegroups.com.
To post to this group, send email to hamcre...@googlegroups.com.
Visit this group at http://groups.google.com/group/hamcrest-java.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages