At work we have a number of projects which need to share some common code. Some code is completely universal while some of the code is only shared by a subset of our projects. Should I split up the common code into two separate projects or use two different ivy configurations for a single project?
Option 1 – Two separate projects.
- Proj 1 – Common published as default configuration
- Proj 1 – Common-xml published as default configuration
Potential Issues: Requires that I have two separate projects, with two separate build files and two separate ivy files.
Option 2 – One project, multiple ivy configurations for different artifacts
- Artifact 1 – Common published as core
- Artifact 2 – Common xml published as core-xml
Potential Issues: I may have to maintain separate source directories in the same project.
In either case, the common xml component may rely on the common core component.
So, SF, what should I do for maintaining my common code? What issues did I miss with the two methods, and what are any other pros/cons or alternative solutions?
Hmm, it really comes down to how you prefer to manage your source code. But first, I’d be asking the question of whether you really need to split the source. The idea of a commons project is to encapsulate code, classes, interfaces, etc that can be used as a common toolkit by other projects. It doesn’t mean those projects have to use everything in Commons. They might only use a small portion of it. That’s perfectly fine and it might be that splitting your Commons is effectively over optimisation.
Think of this – what happens if your next project uses a different subset of the Commons library? are you going to split again?