Hi,
After a few weeks of working with the post JCR-157 Jackrabbit structure,
I've started thinking about partially reverting the restructuring. The
main reasons for this are:
* Managing the current Jackrabbit build environment is relatively hard
even with the multiproject plugin being used.
* There is no longer a single Jackrabbit jar with an associated set of
dependencies, leading to more complex documentation and deployment issues.
* There is no obvious way to avoid navigational issues across the
component sites generated by the current multiproject setup.
* The unit test, checkstyle, and other reports are split over the
component projects
* The component structure points the way towards an even more fragmented
project structure with separate component projects for example for
individual persistence managers (see the recent "build problems" thread)
Even though I greatly appreciate the benefits of the restructuring
(especially the commons library that I'm already using in a few other
projects) I've come to feel that the problems outweight the benefits.
So, I'd like to propose to partially undo the changes related to
JCR-157. Instead of the full api, commons, and core subprojects, I'd
propose using package naming and design conventions to manage these
components. We could have o.a.j.{api,commons,core} packages within a
top-level ./src/main/java source directory. Additional component
packages (like o.a.j.rmi) could be used if major contrib projects were
to be fully integrated with Jackrabbit. The design constraints (like no
Jackrabbit dependencies in commons) could be enforced either manually or
with some custom Checkstyle checks. The separate api and commons jar
files could still be generated by a Maven postGoal rule. This change
would solve above problems while still providing at least some of the
original benefits.
Comments?
BR,
Jukka Zitting
