At our company, we maintain three products, which are quite similar, in 2 Projects.
All Java, using Maven for dependencies.
These three products evolved out of another project, which is now a maven dependency of the two Projects.
Project A and B are so similar, that essentially every bug fix for A has to be copied or merged for project B.
The Flavors of Project B, on the other hand, describe very distinct differences in behaviour between these two. For example other items in a right click menu. This had been accomplished by very ugly if-else-monsters, which have partly vanished in favor of a more OOP like approach, but now lead to another problem: where to organize these flavor dependent classes?
At the time being, we deploy our projects with profiles for the different maven builds.
Our goal is to merge both Projects (possibly also with the base project) into one with distinct flavors.
My Question is now: how to Organize this?
Our main approach is, to enhance Project B with the features of Project A by defining a third flavor for Project B and let A gradually be superfluous, so that our bug fixes have to be done in only one place.
So We imageined our Project structure roughly like this:
tld.company.project.<all of the logics with dependency injection> tld.company.project.flavor.<flavor 1>.<implementations> tld.company.project.flavor.<flavor 2>.<implementations> tld.company.project.flavor.<flavor 3>.<implementations>
Inside of the business logic, we would then inject one
XyHandler, which is implemented in every flavor and will be populated by our beans.xml
Does this seem to be maintainable? Or even desirable? Every idea is welcome!
The common codebase is just that huge, we have to find a way to combine those two Projects.