I know the reasons for this are historical, and I don't want to change things for Jackrabbit 2: Jackrabbit 2 consists of many distinct projects. For me, this is just far too many, the complexity is overwhelming even for me as a developer of Jackrabbit. I guess it's even worse for users and potential committers. One project only contains one(!) class. In some cases, the code for a feature are spread into different projects. In one cases (that I know of), the unit tests (not just integration tests) for a feature is in a different project than the implementation. In my view, using the same architecture for Jackrabbit 3 would make developing Jackrabbit 3 very inefficient. It increases build time and makes code coverage results partially meaningless. As we have seen multiple times, it is also a pain for users, because he has to add multiple Jackrabbit jar files to his project. There is a risk to combine Jackrabbit jar files that don't work together. I don't know a similar projects that consists of that many projects: Lucene is one project and jar file (lucene-core), and Apache Derby, HSQLDB, and H2 are all one project. In my view, splitting Jackrabbit 3 into multiple projects doesn't help anybody at all (not the user, not the developer, and not the tester).
But for Jackrabbit 3, I suggest to keep all source "core" code in one project, and create one jar file, until we have a good reason to split it into multiple projects. This excludes the TCK (Technology Compatibility Kit) of course, which is a standalone project independent of Jackrabbit. It may also exclude compatibility and performance tests, which are run against multiple versions of Jackrabbit. As for remoting (RMI and DavEx) we may want to re-use the existing Jackrabbit 2 projects, at least at the beginning, or until we have better solutions. It may also exclude "utilities" that are independent of the JCR implementation and that are not required within Jackrabbit itself (but once Jackrabbit needs the utility, it should be within Jackrabbit). What we do need to consider is OSGi, but this doesn't mean we need to split the Jackrabbit core *implementation* into multiple projects or jar files.
