Until now I have been using simple strategy for packages naming in my maven-modular projects. Each package name contains name of the module in which it is placed.
For example, simple project would have this structure:
- smweb-core(module)
-- src/main/java { cz.sm.core(parent package) }
-- pom.xml
- smweb-web(module)
-- src/main/java { cz.sm.web(parent package) }
-- pom.xml
- pom.xml
The problem is that right now I am working on much larger project(more then 2000 java source files) which has been developed for many years. My task is to restructure this project structre into modular one. I sometimes run into creating cycling dependency(modules are pretty much exclusive, but its not possible to make them 100% exclusive) and i resolve this by moving dependency classes between modules. This workaround invalidates my package naming strategy, since there are some classes inside these modules that may belong to absolutely different work-spaces.
First idea which came into my mind is to remove module name from all its packages names. That means there would be one package structure for whole project, but its contents would be divided separately inside modules. Problem with this solution is that one module may not always provide all of the functionality from some of its packages, because it may be placed in some other module.
Second idea is to stick back to first mentioned naming strategy, but for each functionality that has to be moved from another module, i would create package inside current module that contains name of the another module. In mentioned example if smweb-core module would be in cyclic dependency with smweb-web module, i would do following structure when moving dependencies:
- smweb-core(module)
-- src/main/java
{ cz.sm.core(not longer parent package) }
{ cz.sm.web(functionality moved from web module to resolve cyclic dependency) }
-- pom.xml
- smweb-web(module)
-- src/main/java
{ cz.sm.web(not longer parent package) }
{ cz.sm.core(functionality moved from core module to resolve cyclic dependency) }
-- pom.xml
- pom.xml
For now i do not see any problems coming out from using second naming strategy. My questions are: Which naming strategy should i follow to prevent future problems. Does these naming strategies brake any good practices/design patterns that i should follow? Is there better solution for this problem?
Thank you for all the answers.
Best Answer
Dividing the same java package between projects/artifacts is not a good idea, potentially doesn't even work when combined with signing, classloading and other mechanisms. It is also pretty confusing. This invalidates both proposals if I understood you right.
The root of the problem is that you have cyclic dependencies, which is likely a result of forcing a structure onto the project that it doesn't have. Frequently this is because of technical packaging instead of letting the functionality drive the structure.
What I mean is, there shouldn't be "web", "core" and similar packages. That is just arbitrary grouping of stuff. Package names should communicate functionality just like class names and method names. So one package should contain every technical aspect it needs for one single functionality.
This way your dependencies become "real" dependencies, like "cash transfer" depends on "accounts", or whatever, instead of technical dependencies like "web" depends on "core".
Here is an article of mine about this subject: Happy Packaging!