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.
If named interfaces are declared in nested packages, the name detection might accidentally pick up the names declared in child packages. We now deliberately only inspect the base package.
As we process a type's entire type hierarchy for dependencies we might discover a foreign module's internal dependencies for modules that declare allowed dependencies explicitly. Explicitly declared dependencies so far solely verified the target being explicitly listed, which, for internal dependencies does not make sense. We now immediately start checking the source and target modules to be equivalent, in which case we can skip any further processing.
We now expose a configuration property spring.modulith.detection-strategy that can take either of the two prepared values "direct-sub-packages" (default) or "explicitly-annotated", or a fully qualified class name of the strategy to use.
Removed ApplicationModuleStrategies enum to avoid exposing the enum values as additional implementations. Those are now held as inline lambda expression in the factory methods on ApplicationModuleStrategy. Extracted the lookup of the strategy to use into ApplicationModuleDetectionStrategyLookup for easier testability.
The previous change unfortunately altered the CacheKey type in a way that it does not result in equal instances for the same set of parameters, primarily because SingletonSupplier does not implement equals(…)/hashCode(). We now resort to include the ModulithMetadata source in the equals(…) / hashCode() calculation rather than the ModulithMetadata instance itself. This also avoids annotation processing during CacheKey instance creation.
Previously, we had a variety of places calculating the overall packages to inspect for types. This is now all consolidated into the ModulithMetadata abstraction exposing them directly.
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).
We now guard the annotation predicate for @Generated behind a classpath check to avoid a NoClassDefFoundError on previous versions of Spring Framework.
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.
Removed the inclusion of the spring-modulith-runtime artifact from the …-starter-core one to avoid issues in native images in a Spring Modulith default setup. As the artifact is still needed to support ApplicationModuleInitializer implementations, we now explicitly check for the presence of those and verify the artifact is actually available and hint the user at explicitly adding it if missing.
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).
Prior to this commit, the lookup for an ApplicationModule would find modules solely depending on the reference string starting with the base package. That means that a module with base package com.acme.foo, a request for com.acme.foobar would've resulted in a positive match, which of course is wrong.
We now match against either the module's base package or against the reference starting with the base package followed by a dot.
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.
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 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.
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.
