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.
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.
Slight rewording of the section talking about the usage of application module detection strategies with runtime components. Added notes in both the runtime support and production ready features chapters to point to the new instructions.
A bug [0] in APTK causes our Javadoc extraction to fail for methods whose parameters are classes nested in interfaces. We fix that by temporarily including a fixed copy of TypeElementWrapper, that looks up outer types on interfaces as well.
[0] https://github.com/toolisticon/aptk/issues/163
