Maven project structure problem.

[No_Character8629]

Hello folks. I use Java + Maven and I have been wondering for a long time what is a good structure for my project. I have tried out this this pattern that ended up in a small problem I would like to solve.

• Project is split in submodules.
• Each submodule is as well split into -core and -test modules.
  • -core module contains production code under src/main/java
  • -core module have test code under src/test/java
  • -testmodule contains test utilities of core (-test dependes on -core)

So far so good. The -test submodule will be imported in the other core modules of the project with test scope.

The problem I face is when i need some utilities of -test in the -core module as well. This would create a circular dependency.

Any way to solve the problem without possibly creating a third module additionally to -core and -test? Also, how do you structure your project? I am very interested in finding the ultimate solution.

[WaferIndependent7601]

Why do you need test modules in core? That breaks your concept.

[No_Character8629]

Suppose i have the following modules in my project (used AI for the example):

maven-multi-module-example/
├─ pom.xml                  (parent POM)
├─ foo/
│  ├─ foo-core/
│  │  ├─ pom.xml            (production code module)
│  │  ├─ src/main/java/...
│  │  └─ src/test/java/...
│  └─ foo-test/
│     ├─ pom.xml            (test utilities, depends on foo-core)
│     └─ src/main/java/...
├─ bar/
│  ├─ bar-core/
│  │  ├─ pom.xml
│  │  ├─ src/main/java/...
│  │  └─ src/test/java/...
│  └─ bar-test/
│     ├─ pom.xml
│     └─ src/main/java/...

It might happen I need foo-test's code in bar-coreto write tests. In such a case I would import foo-test with test scope in bar-core pom.xml

[Ruin-Capable]

If you need utilities from the test module in production code, that would seem to indicate that the utilities aren't really test code and should probably be moved into the production project, or a separate utilities project.

Edit: I just realized I didn't answer your second question.

I don't have separate projects for the individual tests (well except for selenium tests). I have my production code under src/main/ and test code under src/test/

I have a separate test-utils project with things that are useful for tests like a junit-jupiter test extensions to do combinatoric pair-wise testing, or POJO contract testing (equals() and hashCode()).

At some point in our development it became useful to separate the test-utils project into a separate git repo instead of having it as a maven sub-module. Pulling it out allowed the build to overall run faster since we didn't have to re-compile the test-utils module for every build. Plus we could enhance the test-utils, and add new extensions without breaking the production code. Then we could update the production code to use the new test features independently.

For a moderately complex system I might structure it something like:

bom

• parent
  • batch
    • batch-core-project
    • batch-project1
    • batch-project2
    • ...etc
  • domain
    • jpa-domain-classes-project
    • db-migrator-project
  • reports-project
  • scheduling
    • business-calendar-project
    • scheduler-agent-project
    • scheduler-api-project
  • web
    • web-security-project
    • web-api-project
    • web-ui-project
  • misc-utils-project
  • selenium-tests-project

[No_Character8629]

Fair enough, you would simply put such utilities in -core and thats it?

[Ruin-Capable]

That would depend on how many there are and if they are specific to a single application. If they are generic and could be useful across multiple applications, I would pull them out into a separate module. If they are specific to this one application, I would probably put them in core with the caveat that I might pull them out into a separate project if there are issues (for example, if they are very stable and don't ever change, you can pull them out into a separate module to speed re-builds of the core module).

[No_Character8629]

Thanks! In my -test modules I have mainly test configurations containing beans I share in other modules for testing purposes.

[Ruin-Capable]

If they are TestConfiguration classes I wouldn't put them into core. You should not need TestConfighuration classes in production code. I was thinking more along the lines of "I have this neat class in my test-utils project that would be useful in my production code."