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
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-1041 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.
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.
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.
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.
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.
Prior to this commit, running our tests caused the following warning because Mockito was dynamically self-attaching to the running JVM:
Mockito is currently self-attaching to enable the inline-mock-maker. This will no longer work in future releases of the JDK. Please add Mockito as an agent to your build what is described in Mockito's documentation: https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/Mockito.html#0.3
We now follow the advice in the provided link and set up our build accordingly.
