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)
Message-ID: <42D2A13C.8070109@zitting.name>
Date: Mon, 11 Jul 2005 19:41:32 +0300
From: Jukka Zitting <jukka@zitting.name>
User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513)
MIME-Version: 1.0
To: jackrabbit-dev@incubator.apache.org
Subject: Re: build problems
References: <C2CDEFBECFC9A14892BCCFB4C95F4868389F44@EX-201.mail.navisite.com>
	 <8be73188050702085725c3b924@mail.gmail.com>	 <42C6BE4C.7090803@yukatan.fi>
	 <e678310c837c18c7174363989c7326ca@gbiv.com>	 <42D0D597.9040700@yukatan.fi>
 <90a8d1c00507110126aa6cdbb@mail.gmail.com> <42D24065.1080200@yukatan.fi>
 <48f091cace2e8e35d49d9370487aada5@gbiv.com> <42D266AE.8010506@yukatan.fi>
 <b7b23c65a5c2f34f6cfead9bab201093@gbiv.com>
In-Reply-To: <b7b23c65a5c2f34f6cfead9bab201093@gbiv.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Roy T. Fielding wrote:
> I think it is a question of independence. AFAICT, the various gateways
> under contrib are entirely dependent on the Jackrabbit project at the
> moment and it would be very difficult for them to live independently.
> JNDI, RMI, and webdav access seem to be very much in scope even when
> they are coded to be independent of the JCR implementation, since
> their purpose is to serve as deployment methods.

At the moment yes, as there are yet only a few real JCR implementations 
out there, but what about later. The gateway components as well as the 
underlying "commons" code is definitely useful for other projects as 
well. Treating them as ordinary parts of the Jackrabbit implementation 
will introduce troublesome partially-outside-the-project-scope 
components within Jackrabbit. Of course this is also the current 
situation, but at least we now have the contrib subdirectory keeping the 
line... :-)

Another point to consider in drawing the scope line is the architectural 
layering of the components. Many of these components in question live at 
the opposite side of the JCR API layer, and thus considerably widen the 
architectural scope of Jackrabbit.

     +-------------------+
     | RMI, Webdav, etc. |
     +-------------------+
     |        JCR        |
     +-------------------+
     |     Jackrabbit    |
     +-------------------+

> Both RMI and webdav are useful deployment mechanisms and, as such,
> should be managed by the project and released as such for now.
> Do you think that they are sustainable outside Jackrabbit?  I mean,
> do you think that Apache could eventually organize at least three
> independent collaborators to run such a project outside of
> Jackrabbit?  I have a hard time believing that will ever be the
> case, since interface layers tend to be one or two-person projects.

Not as separate projects perhaps, but I certainly see a need for a 
common implementation-independent base of JCR components and tools. If 
such a base should not be maintained within the Jackrabbit project, then 
perhaps we should revisit the idea of a Commons-JCR project that was 
briefly discussed during the last winter.

I think that a Commons project that would include for example RMI ja 
Webdav layers and the recently added commons-chain commands in addition 
to the general-purpose support code (ISO8601, Value handling, etc.) from 
jackrabbit-commons could easily support a diverse-enough community for 
the project to stand on it's own.

What's the general opinion about this?

>> I'm a bit worried about essentially renaming everything. Even if the 
>> original component names perhaps aren't perfect, there's already quite 
>> a lot of community buy-in, existing code, and mailing list references 
>> to names like jcr-rmi and orm-persistence.
> 
> I don't buy this argument.  There is no dependence on the existing
> names, but there will be six months from now.  We haven't made a
> release yet and we are still in incubator, so I can't accept an
> argument that there is a lot of buy-in from the community, and
> the fact that it will become harder very soon should be motivation
> to get the names right now.  We need to imagine how people will
> view the release and choose names according to the goal of helping
> them understand.  I want those names to be as clear as possible
> before we spend a great deal of effort over the next few months
> on documentation.

OK, you're probably right. Little pain now to avoid bigger pain later. I 
can live with this. :-)

BR,

Jukka Zitting