Coverage increased (+0.05%) to 91.742% when pulling f3e1d47 on krystiankaluzny:master into c9a4571 on xmlunit:master.

Many many thanks, I'll need some time to digest this :-)

Great! 👍 I am looking forward to using this!

I think it would be a good idea to rename the 'negative' assertions methods so that they are closer to the AssertJ naming schema: (e.g. hasNotXPath -> doesNotHaveXPath, notExists -> doesNotExist so they read similar to AssertJ Core assertions like doesNotContain, doesNotMatch...). What do you think?

A nitpick: Replace \n with %n in error messages to make them platform independent.

I wonder whether we'd want to put the module into a profile that is triggered if Java is not Java6 in order to avoid the Travis CI problem. So far I haven't seen a reason to drop Java6 support for Core but wouldn't see any problem with the assertj module requiring even Java8 instead. I've been cutting releases using Java8 anyway.

You may want to override the compiler properties in the module's POM if you want to use Java7+ features.

@krystiankaluzny if you are fine with 3a76af0 I'll happily merge that branch (or you push it here and I merge the PR)

@bodewig I think it's fine, you can merge the PR

Thanks, merged. I'l tweak a few things later like adding license headers, adding to the release notes and so on. Also I now realized the openjdk6 build has been broken since I switched xmlunit.org to https so the error wasn't related to the PR at all - something I need to look into separately. Many thanks again!

It would be nice if you (or anybody else more familiar with AssertJ than myself) could add an example to the README and maybe even add a page to the user guide.