I have a large java project, and we use maven for our build cycle. This one project is used extensively - in other projects, in various applications, some of which are contained in it and some which are elsewhere... To be honest, it's a bit of a mess (various bits added on at different times for specific purposes), and I'd like to clean it up a bit. Also, it's not fully tested (lots of bits have been added on without proper unit and integration testing), and there are some tests that take a long time to run or don't actually pass... (uh-oh) - so tests are switched off in the maven build cycle (again, uh-oh).
I am thinking about separating this large project into smaller specific projects, such that the 'final' sub-project (or several sub-projects) would pick up the various sub-projects that it would need.
My thinking is as follows:
- if I separate the big project into various sub-projects, this makes it clear what each project's responsibility is.
- by separating into sub-projects, I can then clean up the testing of each sub-project individually, and turn on the testing for that sub-project in the maven build cycle.
I am slightly concerned about what impact this might have on the build time.
- Would imposing a structure on the large project (i.e. into smaller sub-projects) slow the compiler down?
Also, I have a slight concern on what impact this might have editing time in IDEs (we principally use Intellij). Intellij seems to build each project in turn through the dependency tree - i.e. if C depends on B depends on A, and I change A, it won't try to build B unless A compiles, and so on. Arguably that's advantageous, but I have found that if - for example, I change an interface in A that is widely used in B and C, it takes some time to fix all the errors from that change...
Another question is how to use factory classes. Some aspects of the project depend on external jars. Occasionally (thankfully not often) these are updated, and we have to migrate. We tend to handle this by using a Factory class which points to the correct versions of the external code (so we don't have to change all the implementations throughout the code base).
At the moment this is all in the large project, but I am thinking that by switching to sub- projects, I could develop a new project for the implementation of new external code, make sure that sub-project is fully functional and tested, and then switch the dependencies / factory class in the user project. However, this is made more complicated by the extensive use of interfaces throughout the large project. For example
- sub-project A - contains interfaces
- sub-project B - depends on A for interfaces and old external jar
- sub-project C - depends on B (and thus A and old external jar), and contains a Factory class that uses B's implementations of interfaces
If I need to change the external jar of B, I can:
- create sub-project B_ii - again depends on A, and now the new external jar
- once fully functional, I can add C's dependency to B_ii, and change the Factory class to use the new implementations of interfaces.
when that's all working, I can then remove C's dependency to original B, and if desired, remove sub-project B.
Is that a sensible way of going about this?
So, in general, my questions are:
- Does anyone have any experience of breaking up large projects? Are there any tips/tricks that you would be willing to share?
- What impact did this have on your development and build times?
- What advice could you offer on structuring such a break-up of such a project?