The configuration classes declaring SpringBootApplicationRuntime and ApplicationModulesRuntime beans now describe them as infrastructure beans so that they do not get reported as eagly initialized as their initialization will be triggered when creating the BeanPostProcessors our observability support is based on.
The configuration of the observability support now consistently refer to ApplicationModulesRuntime directly and to the Tracer instance via a supplier as the latter is only needed during the actual component invocation while the former is already needed to decide whether to decorate the instances in the first place. Simplify the inheritance arrangement underneath ModuleTracingSupport.
The logging adapter for ApplicationModuleInitializers now properly unwraps proxy types so that the log output uses the user classes properly.
Application modules can now declare instances of ApplicationModuleInititalizer to execute code upon an ApplicationStartedEvent.
This is achieved by registering a corresponding ApplicationListener in SpringModulithRuntimeAutoConfiguration to invoke all instances of AMI sorted via the Comparator introduced in GH-102. To make sure that the invocation order follows topological order, the runtime module strongly depends on JGraphT.
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.
In case AssertJ is on the classpath, test cases using the PublishedEventsExtension (for example, implicitly activated via @ApplicationModuleTest) can get an AssertablePublishedEvents injected into the method. In contrast to the original PublishedEvents, that one acts as AssertProvider so that it can be used in assertThat(…).… expressions to verify application events published.
Polished API in PublishedEvents for a more consistent experience.
Introduce Spring Modulith Actuator module to expose the application module structure as Spring Boot actuator. This required a Spring Modulith Runtime module to be extracted from the Spring Modulith Observability one. The former now contains the auto-configured ApplicationRuntime and ApplicationModulesRuntime bean instances to be able to bootstrap a ApplicationModules asynchronously on application startup. The actuator module then contains a Spring Boot @Endpoint implementation consuming the ApplicationModules to render JSON describing the application module structure.
We now provide @ApplicationModuleIntegrationListener as shortcut for the combination of @Async @Transactional @TransactionalEventListener to provide a dedicated annotation for the recommended integration arrangement.
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.
Adapt to API changes in Micrometer and Spring Boot's test context loader API now exposing a checked ContextLoadException to signal failures during ApplicationContext bootstraps.
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.
Added dedicated prepare-release profile to make sure that all modules get their versions updated on mvn release:prepare. This is required to make sure the tag lands on a commit that especially has the distribution module updated so that the documentation publication actually produces the artifacts for the released version.
