ApplicationModules.verify(…) and ….detectViolations(…) now has overloads taking a newly introduced VerificationOptions instance that allows registering additional ArchRules to be executed as part of the verification or disable / replace them entirely.
Prior to this commit, the TypeExcludeFilter registered by @ApplicationModuleTest decided whether to include a type based on the ApplicationModules instance and the content of the modules' backing JavaPackage instances. Those in turn always consider the classes scanned by ArchUnit to decide whether they include a type or not. As an ApplicationModules instance is set up to only consider production code, any type located in the test sources was disregarded from component scanning.
The checks for package inclusion for a test execution have now been revamped to consider the sole package names when filtering types for inclusion.
We now resort to a simple iteration over the types within a Classes arrangement to detect all classes residing in certain packages. This is primarily used during the JavaPackage data structure construction as it's called for every sub-package of a package originally created from a Classes instance. The new simplified algorithm avoids set up of DescribedPredicate instances to eventually only perform simple package name checks.
The fix for GH-1039 introduced a performance regression as the calculation of the sub-packages escaped the SingletonSupplier and thus is now included in every hashCode() calculation. Took the chance to significantly revamp the sub-package calculation for nested packages. In other words, the entire sub-package arrangement for a package is calculated once with pre-computed intermediaries held instead of re-computing them per sub-package.
This is to make sure that marker types annotated with @PackageInfo are considered, too. Deprecate JavaPackage.getAnnotation(…) as it's not used anywhere anymore and we would like to consistently consider package info marker types when looking up package annotations.
Introduce ApplicationModuleIdentifiers as abstraction for an ordered collection of application module identifiers.
Introduced ApplicationModuleMetadata as abstraction for the generated metadata (usually located in META-INF/spring-modulith/application-modules.json) to expose the information we currently need to downstream infrastructure components. Migrated the components introduced to execute ApplicationModuleInitializers to AMA and adapt auto-configuration accordingly.
We now implement the topological sorting of application modules ourselves. Properly recalculate module order after ApplicationModules recreation with shared modules. Make iterator resilient against premature invocation by falling back to the unordered modules.
Cleanup of generated type ignorance.
Before this commit, ApplicationModuleSource inspected all package-info.java contained in given packages, including the sub-packages of those. That caused identifiers explicitly defined in an @ApplicationModule on a package-info.java in nested packages picked up for top-level packages. This is now fixed by only considering the files in the top-level packages.
ApplicationModuleInformation is now public as it's referenced from the ApplicationModuleDetectionStrategy SPI. Extracted ApplicationModuleInformationFactory to avoid the internal instance creation logic from leaking.
The detection of NamedInterfaces for an application module can now be customized by implementing ApplicationModuleDetectionStrategy.detectNamedInterfaces(…). The default implementation of that methods uses the previously default NamedInterfaces.of(…) lookup.
NamedInterfaces and NamedInterface now expose factory methods to be able to construct and combine (through NamedInterfaces.and(…)) instances manually. In particular, the newly introduced NamedInterfaces.builder() method allows setting up a detection configuration that allows picking up packages by naming conventions.
We now detect event types a listener is interested in declared in annotations for inclusion the reference documentation. This allows for the rare case that the event listener method not actually declaring the event type as parameter as it might not be needed in the payload but only the fact that an event was published at all.
We now consider all methods that are (meta-)annotated with Spring Messaging's @MessageMapping which is consistently used in a lot of broker annotations such as @(Rabbit|Kafka)Listener etc.
We now properly translate jMolecules' @Module declaration configuring the id attribute explicitly into the identifier used for an application module.
Introduce @ApplicationModule(id = …) for Spring Modulith-native identifier customization.
Introduced ApplicationModuleIdentifier that ensures that identifiers chosen for application modules do not contain a double colon (::) as we need those as separator characters for manual dependency declarations referring to named interfaces.
