Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v622)
In-Reply-To: <42E6C8F7.7090103@zitting.name>
References: <42E6C8F7.7090103@zitting.name>
Message-Id: <630dc7bdb34cbed5549493a88e2e2d6b@gbiv.com>
From: "Roy T. Fielding" <fielding@gbiv.com>
Subject: Re: Rethinking the great split
Date: Tue, 6 Sep 2005 17:35:44 -0700
To: jackrabbit-dev@incubator.apache.org
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

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