Hamcrest 4.0 Draft #443
Hamcrest 4.0 Draft #443
Conversation
…o Issue249-jdk17 � Conflicts: � hamcrest/src/main/java/org/hamcrest/collection/IsUnmodifiableCollection.java � hamcrest/src/test/java/org/hamcrest/collection/IsUnmodifiableCollectionTest.java
Introduce a new matcher `containsParallelRunsOf` and express the existing `containsInRelativeOrder` matcher using the new matcher with a single run as argument.
to fix javadoc formatting
The expected strings now use System.lineSeparator() instead. Closes hamcrest#438.
For now, starting with FeatureMatcher and TypeSaveDiagnosingMatcher since those are, in my experience, the two most important and commonly used matchers.
Has matchers for java.nio.file.Path class. Replacement for FileMatchers.
Close code section correctly
…Hamcrest.git into Hamcrest_4_0_Draft
…sts_Fail_On_Windows Fix tests that fail on Windows because of Line Separator mismatch.
Property util tweaks
Allows to containsInAnyOrder with a Comparator
Implement a matcher for parallel runs in iterables
Issue249 jdk17 - I am merging this so that I can review it properly. I may revert afterwards if it fails review.
Like breaking a large function into smaller functions, moving the code into individual inner classes should help with maintenance.
The aggregate matcher (isUnmodifiable()) is still failing because the description is not being set. This seems to be an issue with the aggregating matchers (allOf(), anyOf()).
The mismatch description provided by anyOf() is not helpful (it just calls toString() on the item being tested). This is not a fault but just a limitation of what it can do in the general case. By providing a custom IsUnmodifiableCollection Matcher class we can produce a better mismatch description.
Add two public methods to FileMatchers. The matchesContentOf takes a File and returns a Matcher<File> that matches the content of the file. The aFileWithContent takes a Matcher<String> where the string is the expected file content, and returns a Matcher<File> matches the content of the file.
These correspond to the recently added FileMatchers matchers.
|
@tumbarumba - I just noticed that there's section under docs/javadocs with the JavaDocs. I take it this gets generated manually and then checked in for a new release. Should I do that and include it in this PR? Are there other "release" activities that I can do as part of this PR that would take some of the load off of your plate? My goal for this PR would be to perform as many tasks as I can (as a contributor) so that it minimizes the amount you (as a maintainer) have to do to get the release out. |
|
@tumbarumba I have figured out the JavaDocs and will commit an updated version. I have some Javadoc comment cleanup to do as part of that process. It may take a day or two... |
Corrected copy/paste errors.
Since this is a factory class, the constructor was made private to prevent instantiation.
|
@tumbarumba OK, I have updated the JavaDocs. Are there other "release" activities that I can do as part of this PR that would take some of the load off of your plate? My goal for this PR would be to perform as many tasks as I can (as a contributor) so that it minimizes the amount you (as a maintainer) have to do to get the release out. |
I hadn't spotted CHANGES.md, so I created my own RELEASE_NOTES.md for the same purpose. This commit moves RELEASE_NOTES.md content into CHANGES.md.
This PR represents a potential Hamcrest 4.0 release. It is based on Java 17 as a base. Project dependencies that have been upgraded to the latest versions and has PRs that have been submitted to the Java Hamcrest project.
It is currently a draft PR. I will continue to add as many existing PR submissions to it as I can, starting with the most recent PRs and working my way backwards to older PRs. I will review each PR before adding it and may make some adjustments I think are necessary and/or desirable.
My intent it to make it easy for one of the project maintainers to merge this PR into the master branch rather than have to spend the time updating and merging the individual PRs one at a time (i.e. I will spend the time performing that work into this PR so that a maintainer does not have to).
I am hoping that this will kickstart the Hamcrest 4.0 release process. I would like to see this project continue.