We now ship our own APT (included in the core starter) that automatically extracts the user code's Javadoc into a metadata file in generated-spring-modulith/javadoc.json. The documentation generation support picks up that file through SpringModulithDocumentationSource. Asciidoctor has been extended to make more use of the Javadoc where ever it renders a plain type.
Initital prototype to support optimized test execution based on the Spring Modulith application module model. The change introduces a new artifact spring-modulith-junit that extends JUnit's test execution lifecycle. It obtains the ApplicationModules model for the application and potentially skips test classes for execution in case the changes made to the application reside in modules the current test case's module does not depend on.
Co-authored-by: Lukas Dohmen <l.dohmen@yahoo.de>
Co-authored-by: David Bilge <david.bilge@gmail.com>
As @Module is absent from the Kotlin flavor of jMolecules, code that refers to that is now guarded with a more specific check for that type in particular.
Actively reject attempts to use a dedicated schema with SQL Server. Prevent schema reset being executed if no schema is used. Properly report exception during database name detection.
Original pull request: GH-808.
ApplicationModule now exposes both getDirectDependencies(…) and getAllDependencies(…), the former as alias for the now deprecated getDependencies(…) for symmetry reasons. The latter recursively resolves transitive dependencies.
We now optimize the dependency analysis by skipping types residing java and javax packages as they're not relevant to our dependency arrangement model. A few additional optimizations in ApplicationModuleDependencies to avoid iterating over each establishing dependency if all we need to look at is the general module dependency arrangement.
Improve performance of ApplicationModule.contains(…) checks by checking whether the given type can even live inside the package space of the module.
We now expose ApplicationModuleSourceFactory as Spring Factories-based SPI interface to further contribute ApplicationModuleSource instances either from a provided root package subject for module detection through a (potentially customized) ApplicationModuleDetectionStrategy or by explicitly listing particular module base packages.
We now expose a spring.modulith.events.completion-mode property, defaulting the previous behavior to a value of UPDATE. The property can also be configured to DELETE, which will cause the persistence implementations to flip to removing the database entries for event publications instead of setting the completion date.
The ApplicationModules bootstrap now triggers the module base package detection, followed by a new, additional pass of detecting nested application module packages. Those packages are now added to the ones we create ApplicationModule instances for and also handed into the module instance creation step as exclusions to make sure that parent modules do not include code residing in sub-modules.
The bootstrap of ApplicationModules now uses a dedicated ApplicationModuleSource to allow calculating a default module name relative to the application base package.
Each module now operates on the Classes instance obtained from the JavaPackage instance that constitutes the module's base package but filtered by the given exclusions.
