Skip to content

Conversation

@mkoncek
Copy link

@mkoncek mkoncek commented Oct 16, 2019

No description provided.

@coveralls
Copy link

coveralls commented Oct 16, 2019

Coverage Status

Coverage increased (+0.1%) to 92.146% when pulling 18e40ad on terminus-brut:port-hamcrest into 279bcec on xmlunit:master.

@bodewig
Copy link
Member

bodewig commented Oct 16, 2019

Thank you @terminus-brut !

After this change the matchers would no longer work with Hamcrest 1.x, is that correct?

If so I'd probably rather add an additional xmlunit-matchers2 or so project that was tied to Hamcrest 2.x rather than breaking things who don't see any pressing need to upgrade Hamcrest.

On a related note, do the current matchers not work for Hamcrest 2.x? If they do, why would we want to upgrade the dependency?

@mkoncek
Copy link
Author

mkoncek commented Oct 17, 2019

Hi, I am not sure if you will want to accept this, but in case you will, the PR should be correct.
I am maintaining some Fedora packages (including xmlunit) with the latest version of hamcrest and I ported about 3 packages this way.
According to this: https://github.com/hamcrest/JavaHamcrest/blob/master/CHANGES.md#breaking-changes-for-21
the @factory annotation was removed so this caused issues.

But you are right, there is probably no need to update if you don't need to.

@bodewig
Copy link
Member

bodewig commented Oct 17, 2019

I think here is a difference between an application and a library.

As a library the dependency we specify will set a lower bound for the version our users can use themselves - Maven exclusions and similar tricks ignored. They are free to pick newer ones. Therefore I tend to not update dependencies unless there is a good reason to, as this allows our users more freedom of choice.

Judging from the code changes you've made - dropping an annotation - I'd expect the existing matchers to work with Hamcrest 2.1 as they are. In that case I'd rather not update.

Many thanks for your PR, though. And many thanks for maintaining he Fedora package for us :-)

bodewig added a commit that referenced this pull request Dec 29, 2019
@bodewig
Copy link
Member

bodewig commented Dec 29, 2019

I've added a small maven project with commit 9e237e8 that runs xmlaunit-matcher's own unit tests with Hamcrest 2.2 and it seems to work. Therefore I don't see a reason to upgrade the dependency immediately.

I'll need to add running the test to the travis pipeline, but will have to fix that first, I'm afraid.

@koppor
Copy link

koppor commented Jun 21, 2025

Maybe, it is time to update to Hamcrest v3.0 and enforce Java 1.8+.

Background: I found this, because my code doesn't build using gradle. Maybe because different hamcrest versions are mixed (1.x und 2.x). Since @Factory was removed in HamCrest 2.0, I would really vote to re-consider this PR.

@bodewig
Copy link
Member

bodewig commented Jun 21, 2025

Are you seeing any real problem?

The compiled xmlunit-matchers artifact works with Hamcrest 2.2 - at least it does for XMLUnit's own tests. We test this with each CI run, see https://app.circleci.com/pipelines/circleci/V6g9K7YQzERoCkGuNKbmF2/NCancriyEKnFRq6b7UPeyc/54/workflows/547bce4f-3908-4b49-b497-87b48a44ee68/jobs/241 for example.

Right now we haven't got any compat tests for Hamcrest 3.0, but I've just tried them manually and they just work - will add them to CI in a few minutes. From my POV you can simply tell gradle to use Hamcrest 3.0 and it should work. If it doesn't then please open a new issue so we can have a look at it.

BTW, it is extremely unlikely that I will notice a comment on a closed issue or PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants