Gradle's APT handling seems to significantly differ from Maven's as the Java compilation runs from a completely different base folder than the actual project compiled. Even more so, for multi-module projects, the base folder is always the same, which causes APT output using Java's plain File API to override itself in a multi-module project.
I've tweaked the output folder detection to look up well-known APT parameters provided by either the Spring Boot plugin (org.springframework.boot.configurationprocessor.additionalMetadataLocations) or KAPT (for Kotlin-based projects, kapt.kotlin.generated) and derive the actual output folder from the values set for those. If neither of these is set, we fall back to the original local folder.
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.
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.
Before this commit the code resubmitting incomplete event publications unregistered them independently of whether they succeeded or not. We now only do that for failed submissions as an error here indicates a failure to *submit* the publication. As the execution is likely performed asynchronously, a successful hand-off does not implicate the publication being completely processed.
The Structurizr Core library depended on by the documentation support artifact pulls in Commons Logging which conflicts with Spring Frameworks spring-jcl artifact. We now explicitly exclude the former to prevent warning logs at runtime.
We now create counters for each cross-module application event published. The counters can be customized through ModulithEventMetricsCustomizer beans registered in the ApplicationContext.
Refactored the packages to let ….modulith.observability become the API package and moved all implementation components into ….modulith.observability.support.
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 rather use an object identity comparison in TargetEventPublication.isAssociatedWith(…) instead of an ….equals(…) as that would return the wrong publication for identical events.
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.