On Jul 26, 2005, at 4:36 PM, Jukka Zitting wrote:
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.
Me too -- I've tried several times to recover a decent website build
from the split directories and I am ready to give up. Since nobody
else has built the site since the split was made, I think it is a
dead end that is hampering progress.
Moving contrib to sandbox also needs to be done, and then deciding
what else needs to be completed before a 1.0 release.
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?
We seem to have no end of bad names. None of {api,commons,core}
are meaningful. api is just a placeholder for javax.jcr.
commons should be o.a.j.util. core should be o.a.j.jcr.
I'd like to have some kind of grouping/distinction of things
like rmi and webdav that act as network client interfaces.
Would "org.apache.jackrabbit.via.rmi" be okay?
....Roy
