GH-418 - Include JSR 303 ConstraintValidator implementations in bootstrap dependency analysis.

Spring Boot configures Hibernate Validator in a way that the latter looks up the components it needs to instantiate via the Spring container. That in turn then creates prototype instances of the types requested. This means, implementations of e.g. ConstraintValidator do not need to be explicitly marked as Spring beans, but could still declare dependencies to other Spring beans. If such a dependency crosses a module boundary, we currently fail to detect that implicitly established module dependency.

This is now fixed by considering ConstraintValidator implementations Spring beans implicitly in out bootstrap dependency analysis.

spring-modulith-integration-test/src/test/java/org/springframework/modulith/core/ApplicationModulesIntegrationTest.java

@@ -37,6 +37,7 @@ import com.acme.myproject.complex.internal.SecondTypeBasePort;
 import com.acme.myproject.moduleA.ServiceComponentA;
 import com.acme.myproject.moduleA.SomeConfigurationA.SomeAtBeanComponentA;
 import com.acme.myproject.moduleB.ServiceComponentB;
+import com.acme.myproject.validator.SampleValidator;
 
 /**
  * @author Oliver Drotbohm
@@ -196,6 +197,20 @@ class ApplicationModulesIntegrationTest {
 		});
 	}
 
+	@Test // GH-418
+	void detectsDependencyInducedByValidatorImplementation() {
+
+		assertThat(modules.getModuleByName("validator")).hasValueSatisfying(it -> {
+
+			assertThat(it.getSpringBeans())
+					.extracting(SpringBean::getFullyQualifiedTypeName)
+					.containsExactly(SampleValidator.class.getName());
+
+			assertThat(it.getBootstrapDependencies(modules).map(ApplicationModule::getName))
+					.containsExactly("moduleA");
+		});
+	}
+
 	private static void verifyNamedInterfaces(NamedInterfaces interfaces, String name, Class<?>... types) {
 
 		Stream.of(types).forEach(type -> {