We now check for the presence of AssertJ on the classpath and rather register an instance of ApplicationPublishedEvents in the ApplicationContext if present.
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.
Both ModuleContextCustomizer and ModuleTypeExcludeFilter contribute to the calculation of the context configuration which the Spring Test Context Framework uses to decide whether it's necessary to create new ApplicationContext instances.
Both of them previously used a Supplier<ModuleTestExecution> to calculate equals(…) and hashCode() which -- by definition -- does not result in the same result even when created with identical input. We now rather use the source class instance eventually backing the ModuleTestExecution, as that is the internal cache key in turn.
Previously, we had a variety of places calculating the overall packages to inspect for types. This is now all consolidated into the ModulithMetadata abstraction exposing them directly.
If Spring Modulith packages were explicitly configured as autoconfiguration or entity scan packages, the test autoconfiguration would fail as it previously attempted to manipulate an immutable list. We now create a copy of that list to fix this.
We now create artificial root application modules for all root packages to detect violations (for example, types located in root packages referring to module-internal types).
