Added a readme to briefly describe what's contained in the examples. Added Maven Wrapper to all example projects.
Limit the dependencies of the JDBC based example to sole Spring JDBC (dropping the Spring Data integration as it's not needed for the example. Remove unused, JPA-related property
The default propagation type of @Transactional is Propagation.REQUIRED. That, however would reuse the already running committed transaction which is not the correct behavior.
Related ticket: #80.
We now register a default customizer on the Scenario instances created to pick up an ExecutorService defined in the ApplicationContext so that customizations made to that are considered in 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 opt out of defining bean definitions for MongoTransactionManager and TransactionTemplate if user defined. We also make sure to run before the EnableTransactionManagementConfiguration to make sure that will see our auto-configured MongoTransactionManager.
As the Event Publication registry only works in transactional environments, we should enable them for MongoDB by default. This will require a replica setup for the MongoDB instance the application interacts with.
We now avoid accessing the ApplicationContext from a BeforeAllCallback as this might cause the context initialization before other extensions had time to kick in.
We now properly check whether one of a Spring bean's implemented interfaces is exposed by the module before including it in the default rendering of the Application Module Canvas.
The dedicated annotation allows using Scenario as test parameter in @SpringBootTest-based integration tests, too.
ScenarioParameterResolver now throws a better error message if a TransactionTemplate bean is missing from the ApplicationContext.
AbstractApplicationEventMulticaster.supportsEvent(…) currently doesn't properly match unresolved, generic ApplicationEvents (see [0]). We now work around this problem by additionally matching the raw event types in a custom override of supportsEvent(…).
[0] https://github.com/spring-projects/spring-framework/issues/30399
We now register default groupings for the architectural abstractions [0] in case they are available on the classpath but still fall back to the standard Spring Framework ones if not. In other words, if you e.g. use the jmolecules-hexagonal-architecture ones, types and packages annotated with @Port will cause the affected types to appear under a "Ports" section in the "Spring components" row in the Application Module Canvas.
[0] https://github.com/xmolecules/jmolecules#available-libraries-1
