anchor.diff:  OSGi where service files are not visible), there is yet another way of contributing constraint
   definitions. You can provide one or more implementations of +ConstraintDefinitionContributor+ to
   +HibernateConfiguration+ during bootstrapping of the +ValidatorFactory+ - see
  -<<example-using-constraint-definition-contributor>>
  +<<example-using-constraint-definition-contributor>>.
   
   [[example-using-constraint-definition-contributor]]
   .Using +ConstraintDefinitionContributor+ to register constraint definitions
  
positive.code: _javax.validation.ConstraintValidator_ to _META-INF/services_. In this service file you list the
  fully qualified classnames of your constraint validator classes (one per line). Hibernate Validator
  will automatically infer the constraint types they apply to.
  See <<example-using-service-file-for-constraint-definitions>> for an example
  
  [[example-using-service-file-for-constraint-definitions]]
  .Using _META-INF/services/javax.validation.ConstraintValidator_ for constraint definitions
  ====
  [source]
  ----
  org.mycompany.CheckCaseValidato
  ----
  ====
  
  
negative.code:             and its default implementation.
  |org.hibernate.validator.parameternameprovider|A ParameterNameProvider based on the
              ParaNamer library, see <<section-paranamer-parameternameprovider>>.
  |org.hibernate.validator.spi.constraintdefinition|An SPI for registering additional constraint validators programmatically,
              see <<section-constraint-definition-contribution>>.
  |org.hibernate.validator.valuehandling,
              org.hibernate.validator.spi.valuehandling|Classes related to the processing of values prior to their
              validation, see <<section-value-handling>>.
  