Currently, my engineering group is in the process of refactoring our application code. The purpose of repackaging the code is to formalize and codify the separation of the different code modules. After repackaging is completed, there will be X distinct packages, where now there are only 2. These packages will have well defined dependencies on one another, and these dependencies will be enforced through the build. Each package will have its own build script. There will be another build script that will build all the packages together.
Currently, we have the following two packages:
1. Base package, call it BASE, containing the low level core architecture code for the webapp. For example, webservices, PDF generation, database connection classes, et al.
2. Whole
j2ee webapp, call it APP. There are 3 APPS to be precise.
I am curious if anyone has any thoughts what works and what does not during a major code refactoring such as this one. What are the key Design and Deployment (D&D) considerations?
After a few discussions, the following code repackaging was proposed:
1. core.jar
2. j2eecore.jar
3. commons.jar
4. functionlity1.jar (engine1)
5. functionality2.jar (engine2)
The newly proposed breakdown may increase the complexity of building and deploying code to PRD servers. In addition, development of new
JAVA or J2EE code may become non-trivial as engineers will need to be aware of interdependencies among 5+ packages.