Upgrade java, maven and versions of other dependencies

[velinovskav]

No description provided.

[marcelstoer]

You also need to change https://github.com/netceteragroup/valdr-bean-validation/blob/master/.travis.yml#L3 for the CI build to pass.

[coveralls]

Coverage increased (+0.8%) to 91.026% when pulling 3af21f3 on velinovskav:master into 6ae2035 on netceteragroup:master.

[marcelstoer]

This is taking shape quite nicely. However, the more I think about it the more hesitant I become. There's a clearly defined mapping between Bean Validation constraints and valdr Angular JS validators as per https://github.com/netceteragroup/valdr-bean-validation#mapping-of-bean-validation-constraints-to-valdr-constraints (which this PR should also update). This is established through a String match from e.g. https://github.com/netceteragroup/valdr/blob/master/src/core/validators/hibernateEmailValidator.js#L12 to https://github.com/netceteragroup/valdr-bean-validation/blob/master/valdr-bean-validation/src/main/java/com/github/valdr/BuiltInConstraint.java#L33. So, if you change hibernateEmail to email you'll effectively use a different validator (the one here https://github.com/netceteragroup/valdr-bean-validation/blob/master/valdr-bean-validation/src/main/java/com/github/valdr/BuiltInConstraint.java#L33).

I'm thinking that maybe we should add support for the Bean Validation email constraint without dropping the Hibernate email support at the same time. They could basically co-exist. However, we could also argue that anyone stuck with the proprietary and deprecated Hibernate stuff should simply not upgrade this library.

What do you think?

[velinovskav]

Sorry for the delay of my response.
In my opinion it's better if there is only one validation constraint for email, if somebody wants to use Hibernate email support, should not upgrade the version of the library.
In order to be consistent I can remove mapping of Email Bean Validation constraint to valdr Email validation constraint.
What do you think?