Metadata declared in jMolecules' @Module not considered

[xenoterracide]

log output

> Logical name: model
> Base package: com.xenoterracide.security.model
> Spring beans:
  o ….controller.RegistrationCtrlr
  o ….user.UserRepository
	at com.xenoterracide.test/com.xenoterracide.test.ApplicationTest.lambda$modulith$0(ApplicationTest.java:26)

my package definition

/**
 * Contains Domain Model classes for security.
 */
@DomainLayer
@BoundedContext(name = "Security")
@Module(name = "Security", id = "security")
package com.xenoterracide.security.model;

import org.jmolecules.architecture.layered.DomainLayer;
import org.jmolecules.ddd.annotation.BoundedContext;
import org.jmolecules.ddd.annotation.Module;

obviously the logical name model isn't going to work. I would think given this output/definition that the logical name would have become security using the id on @Module

If the name/id in @Module isn't supposed to work, is there a way that does? I don't see it in https://docs.spring.io/spring-modulith/reference/fundamentals.html

[odrotbohm]

I've used this ticket to apply an a bit more extensive refactoring to remove a couple of misalignments in semantics. So far, Spring Modulith has always used “name” to refer to an application module's identifier and “display name” as the human-readable variant of that, whereas jMolecules has used “id” and “name”. That's an obvious clash and source of confusion.

In GH-872, I've introduced ApplicationModuleIdentifier to resolve that problem. It also allows us to constrain the tokens to be used as identifiers, as we, for example, use :: as a delimiter between a module name and a named interface in the explicitly declared dependencies in @ApplicationModule(allowedDependencies = …).

On top of that introduction, I've revisited the application module discovery algorithm to properly pick up @Module declarations and the id attribute value of those. I also introduced @ApplicationModule(id = …) as a Spring Modulith-native counterpart of the jMolecules annotation.