jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <ju...@zitting.name>
Subject Rethinking the great split
Date Tue, 26 Jul 2005 23:36:23 GMT

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.



Jukka Zitting

View raw message