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.
Documenter now remembers whether it has cleared the output directory so that multiple attempts to clear on one Documenter instance will not wipe the content previously generated on the same instance. All methods ultimately creating files trigger the one-time target folder wipe now.
Moved file system operations into the OutputFolder abstraction.
A couple of parameter renames for consistency.
When defining allowed application module dependencies to named interfaces, the asterisk can now be used to allow referencing all named interfaces declared by the target module.
Introduce @PackageInfo annotation to allow marking a types as alternative to Java's native package-info.java so that annotation lookups on a JavaPackage will also find annotations placed on that type. Useful to declare package scoped metadata like @ApplicationModule and @NamedInterface for languages that do not support packages well enough (read: Kotlin).
Spring Boot configures Hibernate Validator in a way that the latter looks up the components it needs to instantiate via the Spring container. That in turn then creates prototype instances of the types requested. This means, implementations of e.g. ConstraintValidator do not need to be explicitly marked as Spring beans, but could still declare dependencies to other Spring beans. If such a dependency crosses a module boundary, we currently fail to detect that implicitly established module dependency.
This is now fixed by considering ConstraintValidator implementations Spring beans implicitly in out bootstrap dependency analysis.
We now explicitly exclude classes generated by Spring AOT in the architectural model. For technical reasons, they might introduce dependencies to application components considered module internals otherwise. Also, proxies generated do not need to be considered either.
We now create artificial root application modules for all root packages to detect violations (for example, types located in root packages referring to module-internal types).
The default for @ApplicationModule(allowedDependencies) is now a single element list with a dedicated token we recognize as "all dependencies allowed". This allows users to declare an empty array explicitly to disallow any outgoing dependencies for an application module. Previously, such a declaration would have allowed any dependency.
@ApplicationModuleTest is now meta-annotated with @SpringBootTest. This allows us to remove a couple of declarations that we actually had copied from it (such as the TestContextBootstrapper, the SpringExtension etc.)
The presence of the original annotation allow test-related auto-configuration to inspect @SprignBootTest for particular configuration. For example, we now alias the WebEnvironment to make it configurable for the test execution.
Switch verification of mock beans as Mockito 5.3.0 uses a different MockMaker by default that doesn't add the explicit interface we have previously checked for.
Remove obsolete init- and destroy method declarations from service bean definitions in examples.
We now use Spring Test Context's TestContextAnnotationUtils to lookup the @ApplicationModuleTest annotation to eventually bootstrap an ApplicationModules instance. That ensures that we find the annotation on JUnit 5's @Nested classes.
Introduced ApplicationModulesExporter to render an ApplicationModules instances as JSON directly. To avoid a dependency to a JSON library and as we only have to be able to render rather simple arrangements, we just build up the JSON string ourselves.
ApplicationModulesEndpoint now caches the structure calculated once to avoid repeated work.
We now optionally integrate with the JGraphT library to calculate the topological order of modules based on their dependency structure. That order is then exposed in ApplicationModules' iteration and via ….getComparator().
Renamed FormattableJavaClass to FormattableType and allow it to be created from a plain Class as well.
Moved TestUtils from spring-modulith-test to spring-modulith-integration-test as it's only used there and doesn't need to be exposed to user applications.
Overhauled the module canvas in various ways. By default, we now skip "empty" rows. In other words, if we do not find any published events for example, we skip the entire row. CanvasOptions.revealEmptyRows() can be used to keep those empty rows around. We now also expose all value types and Spring bean references.
Refactored the dependency lookup APIs on ApplicationModule. Both DependencyType and DependencyDepth are now top-level types. Also, ApplicationModuleDependency and ApplicationModuleDependencies were introduced as explicit types. In the course of that, ApplicationModule.getDependencies(…) has got its return type changed from List<ApplicationModule> to ApplicationModuleDependencies. The internal ModuleDependency type has been renamed to QualifiedDependency.
Consistent method overloads to avoid the need to create default instances of customization options. Renamed Options to DiagramOptions for consistency with CanvasOptions.
We now verify detected dependencies against optionally explicitly defined ones. Those can refer to named interfaces (via the "moduleName :: namedInterfaceName" syntax). If such an allowed dependency is defined, all dependencies towards other named interfaces (also the unnamed one) are rejected.
Some Javadoc polishing.
