jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: Rethinking the great split
Date Wed, 27 Jul 2005 07:35:38 GMT
hi jukka,

On 7/27/05, Jukka Zitting <jukka@zitting.name> wrote:
> 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?

personally i would be ok with the change you suggest. i too experienced
the same problems that you described. therefore +1 from me.

however, tobi who initiated the current structure might come up with issues
with the suggested re-restructuring.


> BR,
> Jukka Zitting

View raw message