jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: Rethinking the great split
Date Thu, 08 Sep 2005 01:17:19 GMT
On Sep 7, 2005, at 2:07 AM, Tobias Bocanegra wrote:

>> 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.
>
> well, i still believe that the split is good, especially,
> if we want to develop the jackrabbit api in future. could everything
> be put into one sole codebase of course, but it will be more
> difficult to find cyclic dependencies, etc. if the project grows 
> bigger.
> from my experience with larger, multi-module projects, it is
> crucial to separate the build processes of the individual modules.

When it grows bigger, maybe, but not now.  Jackrabbit is a
project for implementing an API (JCR).  Having some other thing
in the project also called the Jackrabbit API is just too confusing.
In any case, the dependencies are wrong and maven multiproject is
not the way to build stable APIs.  When we want to create a
stable client API beyond JCR, we create a separate interface
definition with its own name and versioning.  There is no need
for separate build trees.

> having a set of good maven goals solves a lot of the multiproject
> problems. i must admit, that i did not invest a lot of time
> adjusting the maven files, i though that there are other
> developers with more maven experience than i have.

It is more than that -- I've already spent a week trying to get
multiproject to generate a usable tree of documentation.  Maven
treats them as separate islands of code/test/docs without any
connections between them -- the menu that multiproject:site
generates is a joke.  It is far easier to build all of the
components as a single project and then use custom xdocs to
describe the architecture, since then all of the detailed
interface xrefs are generated automatically.

> but if it is the common wish, i will adjust the files so that:
>
> - a comprehensive site, including the 'modules', 'contribs' external
>   docs, etc is built.
> - add a mechanism for handling the transitive dependencies
>   (imo, maven 2 is not ready, yet)
>
>> We seem to have no end of bad names.  None of {api,commons,core}
>> are meaningful.  api is just a placeholder for javax.jcr.
> no. api will contain the jackrabbit API with methods that are
> currently not available in jcr (nodetypes, QName, etc). and this
> will be the base for the future jcr 2.0.  it is a pity that few
> efforts were made in creating such an api, since the split.
>
> btw, i thought, org.apache.jackrabbit is a placeholder for javax.jcr 
> :-)

cute.

>> commons should be o.a.j.util.
> ok,
>
>> core should be o.a.j.jcr.
> i disagree. o.a.j.core is totally ok.

core is what you get with a segfault, which is why many Unix backup
systems won't save anything named "core" or under a "core" directory.
"o.a.j.jcr" makes it clear that the code within implements the
"javax.jcr" interface.

>> 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?
> ok for me.

I am really looking forward to getting the tree together again
so that we can start the 1.0 release discussion.

....Roy


Mime
View raw message