One more comment

[Dan Connelly <ds...@adelphia.net>]

The more I work with Graffito ocm the more I like it.   The code is 
first-rate and deserves to leave incubation.  

However, the ocm code has very few dependencies on Jackrabbit.   Why is 
it then to be a Jackrabbit sub-project? 

One can connect this ocm tool to a non-JR Content Repository with very 
little  effort.

For that reason, I do not see Graffito ocm as a sub-project of 
Jackrabbit (assuming "Jackrabbit" is the name of the repository 
implementation).

At the risk of being pedantic, let me suggest to you the idea of an 
Apache Content Repository Project, with Jackrabbit, OCM and CDNUtils 
being co-equal sub-projects (in parallel with the Apache (R)DB Project 
having Derby, JDO and DdUtils as its co-equal sub-projects).

    -- Dan

Re: One more comment

[Jukka Zitting <ju...@gmail.com>]

Hi,

On 9/1/06, Dan Connelly <ds...@adelphia.net> wrote:
> However, the ocm code has very few dependencies on Jackrabbit.   Why is
> it then to be a Jackrabbit sub-project?

Good question! We actually have a number of subprojects that only
depend on the JCR API and not on the specifics of Jackrabbit core, the
JCR-RMI subproject being a good example.

The reason for not having each of those subprojects as separate Apache
projects is that there is not enough of a community to maintain them
independently. In fact the reason for proposing bringing the Graffito
JCR Mapping tool to the Jackrabbit project is that I believe the
Jackrabbit community to be more conductive for the ongoing development
of the mapping tool than the Graffito community.

> At the risk of being pedantic, let me suggest to you the idea of an
> Apache Content Repository Project, with Jackrabbit, OCM and CDNUtils
> being co-equal sub-projects (in parallel with the Apache (R)DB Project
> having Derby, JDO and DdUtils as its co-equal sub-projects).

That might well be something that we'll evolve into eventually (like a
few years from now), an Apache JCR federation, but as of now I don't
think it makes sense to start splitting up the Jackrabbit community
over code boundaries. A good indication of when we might start
considering setting up a separate project is when the developers of a
subproject start asking for their own mailing list instead of using
the Jackrabbit dev@ list for communication.

BR,

Jukka Zitting

-- 
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development

Re: One more comment

[Alexandru Popescu <th...@gmail.com>]

On 9/1/06, Dan Connelly <ds...@adelphia.net> wrote:
> The more I work with Graffito ocm the more I like it.   The code is
> first-rate and deserves to leave incubation.
>

Damn... I have waited for a long time to hear this :-). Thanks.

> However, the ocm code has very few dependencies on Jackrabbit.   Why is
> it then to be a Jackrabbit sub-project?
>

I guess what is more important is that it is JCR API based. So,
Jackrabbit will offer an JCR implementation and tools to develop. Nice
combination, imo.

./alex
--
.w( the_mindstorm )p.

> One can connect this ocm tool to a non-JR Content Repository with very
> little  effort.
>
> For that reason, I do not see Graffito ocm as a sub-project of
> Jackrabbit (assuming "Jackrabbit" is the name of the repository
> implementation).
>
> At the risk of being pedantic, let me suggest to you the idea of an
> Apache Content Repository Project, with Jackrabbit, OCM and CDNUtils
> being co-equal sub-projects (in parallel with the Apache (R)DB Project
> having Derby, JDO and DdUtils as its co-equal sub-projects).
>
>     -- Dan
>
>
>