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.
Instead of iterating over all publications currently in progress we now use a map to look them up by key.
Baseline
--------
Benchmark Mode Cnt Score Error Units
….inProgressPublicationsAccess thrpt 50 312,155 ± 7,428 ops/s
Fixed
-----
Benchmark Mode Cnt Score Error Units
….inProgressPublicationsAccess thrpt 50 2328732,504 ± 7809,092 ops/s
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.
