Open tnaskali opened 5 years ago
This library is for core java types only and not joda time. I'd recommend creating a new library called hamcrest-joda-time to host the joda time matchers.
This seems like a better option indeed. What about creating a "core" generic library and two implementations that depend on it, java and joda-time ?
Hi, really sorry for not getting back sooner and yes the split to a core lib with java and joda implementations may make sense. Before the split though - are you able to raise a PR or create a branch of master with just the changes to support Joda so I can see the extent of the change. This PR contains all the changes for the zone change as well so it's hard to see the scope of the change. If the change looks clean I can look at doing the split in a branch. Regards, Stewart
Hi Stewart, I tried to package all the code to support Joda under the org.exparity.hamcrest.date.joda
package. All the other changes should be related to time zone support. In the meantime I'll try to split them into two separate branches / PRs. Thomas
Hi Thomas, If it's all under the org.exparity.hamcrest.date.joda package then that's cool. I'll pull the PR down and review the diff. No need for you to split it out.
I've re-opened the PR but into a new branch called joda-time.
Support for Joda-Time LocalDate, LocalDateTime, LocalTime and DateTime (compile-only non-transitive dependency to joda-time)