Filter violations to gradually improve

[JosRoseboom]

When adding Spring Modulith to an existing codebase full of violations, the CustomApplicationModuleDetectionStrategy is a big help. However, I was faced with a failure of verify() because a service used field injection. Here it was just a single case and I solved it, but there are codebases where this is the standard way of injecting. Instead of verify in the test you might do something like this:

public void testModules() {

    Set<String> violations = ApplicationModules.of(Application.class).detectViolations().getMessages().stream()
            .filter(message -> !message.contains("uses field injection"))
            .collect(Collectors.toSet());

    Assertions.assertEquals(0, violations.size(), "There are violations:\n" + String.join("\n", violations));
}

In general, this could occur for all kind of violations you don't want to solve now

I see value to add verify(Predicate<String> filter) and detectViolations(Predicate<String> filter) , but maybe I miss a better solution here.

[lukasdo]

For a larger codebase it could be helpful that the ApplicationModules offers a static method where you can parse in a DescribedPredicate, to exclude modules or whatever you might like. However it could be useful to declare some more Filters in ApplicationModules.