I have found splitting a project to many subprojects an efficient way to make it difficult for coworkers to break the architecture by accidentally creating unwanted dependencies.
If a programmer tries to create an illegal dependency, Eclipse won't even suggest importing the depended class, because it doesn't belong to the classpath.
The untrivial part of this strategy are (unit) tests and their utilitity classes (for example mocks). They often need dependencies that are not wanted in the production code (see my blog entry about hsql and openejb for example).
The solution is to create subprojects theproduct-tests and theproduct-testutils and add all needed projects and libraries to their classpaths. Now the source directory for unit tests of any module x is not theproduct-x/tests but theproduct-tests/unittests.
I apply this same subproject principle to 3rd party utilities (both production and test). For example database, xml and xunit libraries all have subprojects of their own. This way I have fine-grained control over dependencies to them, too.
Originally published on 2005-12-14 at http://www.jroller.com/wipu/entry/splitting_project_to_subprojects_for under category Eclipse