Research conflicting ValidationMessages.properties in Beans Validation

[sleberknight]

If two libraries both have ValidationMessages.properties at the top-level, it seems that in Maven the first one it finds "wins". It seems that Maven uses the first one it finds going through dependencies from top to bottom in the POM.

We saw this behavior when migrating one service from the old legacy kiwi library to the new org.kiwiproject one. When the legacy kiwi dependency was first in the POM, its ValidationMessages.properties was used, but if we moved the org.kiwiproject kiwi dependency first, then its version was used. This was a problem during the migration, because validation tests that checked the actual errors were simply getting the validation message keys, e.g. the "interpolated" message would be org.kiwiproject.validation.Required.message instead of "is required".

We need to research what the "best" or recommended practice is within Java Beans Validation so that we don't have our library stomping on custom message bundles, e.g. if we have a service with its own custom validators and its own ValidationMessages.properties. Actually in this case, the one in the service would "win", i.e. we observed that Maven will favor a class/file in the project's source over a conflicting one from a library. I don't know if this behavior is deterministic, but it makes sense that the project's source code "wins" when there is a conflict. This could also maybe be dependent on which tool is used to build a "fat JAR", e.g. we use Shade but others might use something else like the Assembly plugin.

There are a few options and probably more. One is to use the Shade plugin to combine all ValidationMessages.properties files (like we used to do with spring.schemas and spring.handlers). This would assume each message bundle contains unique keys. Since we prefix all ours with org.kiwiproject.validation, that's probably unique.

A second is to figure out if there's a way to build the Validator instances (i.e. in KiwiValidations and also in ValidatorTestHelper in kiwi-test) such that they will aggregate the message bundles.

A third could be to provide a way to specify specific message bundles to use (and make sure the defaults from Hibernate Validator are included).

I'm sure there are other options as well, which we'll need to figure out.

[chrisrohr]

I'm thinking Option 1 is the best bet. I'm not sure how you would find the files in the classpath for Option 2 once the shaded jar has already "overwritten" them. Option 3 seems like a lot of extra work at run time versus build time.

[sleberknight]

See #689 which contains discussion on how to do this. I think we should not use Maven Shade to do this, since it makes too many assumptions (that Maven is used, that the Shade plugin is used) and imposes an intrusive solution that every service, library, etc. would need to do separately.

[sleberknight]

Closing this because #689 covers better ways to implement.