jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: contrib/jcr-ext proposal
Date Sat, 12 Feb 2005 16:28:45 GMT
Jukka Zitting wrote:
> Hi all,
> 
> I've just received committer status with Jackrabbit (thanks for the vote
> of confidence), and would be ready to migrate my private contrib/jcr-ext
> work to the Jackrabbit source repository. Before doing that, I'd like to
> clarify some policy issues raised by Roy.
> 
> Roy T.Fielding wrote:
> 
>>More code sounds great, but I don't want to see a big hierarchy
>>of extension directories.  Please just name them
>>
>>    org.apache.jackrabbit.{meaningful-name}
>>
>>and we'll all work on managing that space.
> 
> 
> I understand the requirement. What I was looking for with the .ext space
> was a grouping of packages that have no dependencies from or to the
> Jackrabbit core packages.
> 
> What would be the policy for managing the org.apache.jackrabbit space?
> For example: Each new top-level package should be proposed on
> jackrabbit-dev before creation. The proposal should contain a
> description of the package (could be used also for package.html) and
> information about who will develop and maintain the package.
> 
> 
>>Contrib should only be used for things that are not managed
>>by the jackrabbit project, with the hopeful intention of moving
>>everything into the main project once the contributor has earned
>>commit status.
> 
> 
> How about the JCR-RMI contrib package? If you want, I could now migrate
> the RMI layer to org.apache.jackrabbit.rmi within the main source tree.
> The Jackrabbit jar would then directly contain the RMI layer.
> 
> However, I'd need to setup separate maven goals to create jars
> containing just the RMI client and server classes. These extra jars
> could be used by other JCR implementations without having to include the
> entire Jackrabbit implementation.
> 
> The same dilemma applies also to the decorator, xml, and other general
> packages I proposed for jcr-ext. Any ideas on how these should be
> handled?

My 2 cents.

I understand that your code is not tied to JackRabbit but only to the 
JCR API layer, but as you seen in many other project implementing things 
both underneath and on-top-of an API, they use a common namespace for 
their stuff.

For example, the webdav servlet in Tomcat is under org.apache.tomcat 
even if nobody has a problem understanding that there is nothing 
tomcat-related in that servlet.

JCR is a way bigger beast than the Servlet API and it's clearly not as 
widely known, but what we are trying to do here is to incubate the 
project and the more 'diversity' in the naming and namespaces and 
'identity' of what JackRabbit is, the harder it becomes.

If we think that JackRabbit is the 'open source reference implementation 
of JCR' i think we will get much less traction than saying that 
JackRabbit is 'the project where you go for JCR-related tecnologies'.

I personally think it would be much easier to incubate the second than 
the first, and your contribution shows very well why.

So, I understand that you might have a dilemma putting your stuff under 
org.apache.jackrabbit since you associate jackrabbit with a 'specific 
implementation' of that API and you don't want people to believe it only 
works with that, but if we think at jackrabbit as a 'repository of open 
source technologies about JCR repositories', thus a little wider scope, 
it will be easier to achive the critical community mass required to exit 
incubation.

-- 
Stefano.


Mime
View raw message