I probably sholdn’t obsess about this too much, but my project has a very structured layout that I have become very fond of. Having that much structure has actually proven to be useful, this time, so I don’t really want it to become messy again.
To start with, each module consists of several Java packages:
com.mycompany.mysoftware.modulename
com.mycompany.mysoftware.modulename.impl
com.mycompany.mysoftware.modulename.osgi
com.mycompany.mysoftware.modulename.test
The main code lives in .impl. Interfaces, some enums and some data container classes that are used by other modules live in the package with no suffix. There’s OSGi specific code (BundleActivators etc.) in the .osgi package and unit tests in the .test package.
Now I have classes that fake a module to be used in testing others. I’m wondering whether I should put those in the .test package of a common module that already contains shared libraries for the main code, or whether I should have a new module test that I can set up a different dependency scope for in Maven.
ETA: One problem I’m having is that I get circular dependencies: if I have two modules and the unit tests in each require a fake of the other, the module containing the fake has a dependency on the module containing the interface, which is the same module that contains the unit test. So, the fake should be together with the test, but that leads to a lot of code duplication. Or, for each module I make a fake module, but that makes me feel it’s getting out of hand…
You don’t want your testing code to be packaged in the common module used by main code, do you?
So the answer seems obvious to me: create a test module and use it as dependency with a test scope.
(EDIT: I’m putting an answer to the problem mentioned in the update of the question below)
Regarding the circular dependencies, what about putting the interfaces in a separated module?