jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject [jr3] One Project
Date Mon, 29 Nov 2010 14:01:16 GMT
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.


Mime
View raw message