We now avoid to initialize the EventPublicationRegistry in the ApplicationEventMulticaster unless there is a transactional event listener interested in the event to be published. This should help us avoid premature initialization of the registry for application events published early in the application context bootstrap phase.
The previous modularity verification arrangement assumed the default module detection strategy to be used. To properly support alternative implementations during the verification we now use a dedicated SliceAssignment implementation that assigns types to slices identified by the module they are located in.
Type based named interfaces on types declared in a module's API package still caused the type to be included in the unnamed interface. This is now fixed by explicitly removing named interface types from the unnamed interface.
We now also detect API package types assigned to a named interface without an explicit name as the package name defaulting doesn't work in this case.
Furthermore, named interfaces are now sorted alphabetically to make the unnamed one always appear first.
We now provide a ScenarioCustomizer that can be used to prepare Scenario instances for test methods with a common customizer. This avoids the need to call ….customize(…) for all Scenarios declared in a test class with the same logic.
Both package- and type-level declarations now use the local package name as the named interface's name. This allows to, at the same time, easily declared named interfaces based on packages but also a nice decoupling of the interface definition and the package layout as individual types can be assigned to such interfaces no matter where they are actually declared.
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.
Altered the bean definition to rather only refer to a ListableBeanFactory and only lookup the ApplicationModulesRuntime and ApplicationModuleListeners when the ApplicationStartedEvent is handled.
Moved the message population for the failure analyzer to the exception to be able to give more actionable feedback and educated users on the cause of the problem.
Adds ArchUnit as an explicit dependency to spring-modulith-runtime. Registers auto-configuration that throws an exception in case ArchUnit is missing from the classpath (as it is likely that it's declared as test scope dependency only) and a corresponding failure analyzer to give guidance on how to solve the problem.
Add sample documentation. Reintroduce Lombok to avoid boilerplate. Use jMolecules DDD abstractions to represent aggregates. Use Scenario API in test cases.
Renamed top-level section to "Production-ready features" to align with Spring Boot. Moved actuator support before observability one. Introduced introductory section to showcase the Insight starter.
To make sure that we trigger transactional event listeners from Scenario based integration tests, we trigger stimulus executions using transactions configured to require a new transaction. This makes sure that Scenarios work in integration tests using @Transactional, of course circumventing the default rollback behavior of those transactions. There's no other way to implement this as we *need* to commit a transaction to trigger the delivery of transaction-bound events.
Fixed a bug in the handling of Scenario.stimulus(Supplier<T>) as for this, the Supplier handed into the method had not been executed transactionally at all.
We now tweak the task executor to await termination for 2 seconds unless explicitly disabled or any of the Spring Boot task executor shutdown properties being set. This makes sure that long running application module listeners do not access resources already in shutdown when running integration tests, in which the context could already shutdown while the listener is still running.
We now use an AsyncTaskExecutor to bootstrap the ApplicationModules instance at startup asynchronously and - at the same time - do not block an explicit application shutdown. This also more idiomatic compared to using an ExecutorService directly.
