spring-projects / spring-projects/spring-modulith

Verification that no classes exist outside Application‘s package

Open
#64 1 comment 0 reactions 1 assignee View on GitHub

@odrotbohm is already working on this.

Since Nov 9, 2022.

type: question
Dominant language
Java
Stars
1.2k
Forks
222
PR merge metrics
No merged PRs in 30d

Description

Hi,

in ArchUnit, there is the possibility to check that there are no classes outside of the packages, for which an architecture is defined.
Wouldn’t this be a nice additional verification for spring-modulith too ?
It would ensure, that there is no other root package besides the application‘s main package.

Maybe this is a non-issue, if all root packages are verified by modulith anyway (?)

So I have some questions to be clear about modulith's conecepts:

1) what are valid root packages ?

└─ □ src/main/java
   ├─ □ com.mycompany
   |  └─ Application.java
   ├─ □ com.mycompany.inventory 
   |  └─ …
   └─ □ com.mycompany.order  
      └─ …

Is "com.mycompany" considered a root package ? Or would that just be "com" ?

2) many root packages ? all packages considered by modulith ?

└─ □ src/main/java
   ├─ □ example1
   |  └─ Application.java
   ├─ □ example1.inventory 
   |  └─ …
   └─ □ example1.order  
      └─ …
   ├─ □ example2
   |  └─ MySneakyServices.java

Is "example2" also regarded as a second root package by modulith and is it allowed to access anything public from example 2 ?

These are my findings, when I experimented with the provided example:
"com.mycompany"

image

...and this also fails to verify dependencies when renaming "com.mycompany" to "example2"

So, my wish would be:

  1. to have the optional 'strict' mode, in which all packages are considered, not just the one where "Application" (main) resides in

  2. to optionally be able to specify root packages like "com.mycompany", so that it is made explicit, and that there is no convention of just considering the first package path "com"

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.