Named interface detection accidentally picks up nested declarations in nested interfaces scenario

[jwedel]

I get this error:

org.springframework.modulith.core.Violations: - Module 'A' depends on named interface(s) 'B :: NamedInterface' via ABC -> XYZ. Allowed targets: common, B, B :: NamedInterface.

So A is a module. Also B is a module. A needs to access NamedInterface which has a package-info.java inside the package with a NamedInterface of 'NamedInterface'.

ApplicationModule 'A' has the following allowedDependencies:

• common
• A
• B
• B :: NamedInterface

Still I get the violation error.

When I change the allowedDependencies as follows, it works without an error:

• common
• A
• B
• B :: *

I'm also using named interfaces in the exact same way in other places and it works perfectly when explicitly declaring it as dependency. I could not find any reason why it does not work, especially as the violoation error message lists exactly that as allowed.

It's really puzzling me.

I'm using 1.2.0 of modulith.

[odrotbohm]

Thanks for bringing this up. Any chance you can provide a reproducer?

[jwedel]

@odrotbohm

Took me a bit, was on vacation :)

https://github.com/jwedel/spring-modulith-dependency-error-reproducer

So, maybe this is not 100% the intended use (we are currently in the process of pulling public api to module root level) but this error message is still kind of weird.

So if you run ModulithApplicationTests then you'll get:

org.springframework.modulith.core.Violations: - Module 'domain1' depends on named interface(s) 'domain2 :: persistence.dto' via com.reproducer.modulith.domain1.Domain1Service -> com.reproducer.modulith.domain2.persistence.Domain2Repository. Allowed targets: domain2, domain2 :: persistence.dto.

If you change the dependencies from module 1 as follows it works:

@org.springframework.modulith.ApplicationModule(
      allowedDependencies = {
            "domain2",
            "domain2 :: *",
      }
)
package com.reproducer.modulith.domain1;

[odrotbohm]

It looks like there's a bug in our named interface detection that currently invalidly assigns Domain2Repository to the persistence.dto interface. That said, once that's corrected, your example still fails as module1 depends on both the presistence interface (via the repository) and the persistence.dto interface (via the DTO). It feels like you're overdoing the technical separation a bit.

[jwedel]

It looks like there's a bug in our named interface detection that currently invalidly assigns Domain2Repository to the persistence.dto interface. That said, once that's corrected, your example still fails as module1 depends on both the presistence interface (via the repository) and the persistence.dto interface (via the DTO). It feels like you're overdoing the technical separation a bit.

On the one hand, as I mentioned before, we are currently on the way of factoring our application. To do this, It would actually help to see some more complex examples either in the documentation or maybe in repository.

Ok the other hand, the separation of public APIs on root level generally sounds like a great idea, but in our case, we have a quite complex application and in this example, the DTO package has around 15 files as our base DTO is quite complex as well. And by the rule of seven, we start introducing sub packages if things grow too much.