Hibernate Validator warnings are displayed when optional ResourceBundles are missing

Describe the bug

When an app depending on the Hibernate Validator extension is package using the native build, the following messages are printed to the output:

The bundle named: ContributorValidationMessages, has not been found. If the bundle is part of a module, verify the bundle name is a fully qualified class name. Otherwise verify the bundle path is accessible in the classpath.
The bundle named: ValidationMessages, has not been found. If the bundle is part of a module, verify the bundle name is a fully qualified class name. Otherwise verify the bundle path is accessible in the classpath.
The bundle named: messages, has not been found. If the bundle is part of a module, verify the bundle name is a fully qualified class name. Otherwise verify the bundle path is accessible in the classpath.

Although that does no harm to the build, it may lead to confusion giving that those bundles are optional.

Expected behavior

Do not print any message if the bundle does not exist in the user’s application

Actual behavior

The message is printed.

How to Reproduce?

1. Clone https://github.com/quarkusio/registry.quarkus.io
2. run mvn clean package -Dnative -DskipTests

Output of uname -a or ver

Fedora 35

Output of java -version

11

GraalVM version (if different from Java)

21

Quarkus version or git rev

2.5.0.Final

Build tool (ie. output of mvnw --version or gradlew --version)

Maven 3.8.4

Additional information

This issue was originated from a chat in Zulip.

Also it seems that this snippet may need to be enhanced to check if the bundle really exists

[gsmet]

Your problem is due to the fact that there is a messages resource bundle in the Kotlin compiler jar:

jar:file:/home/gsmet/.m2/repository/org/jetbrains/kotlin/kotlin-compiler/1.6.10/kotlin-compiler-1.6.10.jar!/messages

and when we are testing if a messages is around before adding it to the native resource bundles, this resource is accessible but it is not accessible at runtime anymore.

@aloubyansky @stuartwdouglas while not critical, this is yet another occurrence of the CL used to test if classes/resources are available at build time being polluted with the build artifacts. What we usually want to do is to test if the thing will be available at runtime (I remember I posted something somewhere about the Infinispan test server polluting the classpath big time).

[gsmet]

https://github.com/quarkusio/quarkus/pull/22938 will fix it once and for all.