jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edgar Poce <edgarp...@gmail.com>
Subject Re: build problems
Date Tue, 12 Jul 2005 04:35:22 GMT
Hi

 > What's the general opinion about this?

Summary:
--------
0 narrow the kind of tools included in jackrabbit
+1 /subprojects folder with a flat structure
+1 /subprojects/sandbox with a flat structure
+1 follow ASF guidelines for preparing releases before moving any 
project from /subprojects/sandbox to /subprojects
---------

IMHO it's true that most of the projects in contrib are out of the scope 
declared in the jackrabbit site[1], and it certainly leads to confusion 
and disorder as Roy pointed. But for a time now there's an apparent 
consensus on seeing Jackrabbit as an umbrella project of jcr related 
"helpers or tools".

Maybe we should review the umbrella idea. What about narrowing the kind 
of tools that fit in the project scope?. If the scope isn't narrowed I 
guess someone should patch the docs.

Regarding the tree structure I think that every contrib project, whether 
released or not, should be placed under a subproject folder. A top level 
flat structure would dilute the jackrabbit main goal, namely the JCR RI.

Despite I admit that the increasing number of projects don't help, I 
don't agree with Roy about the project names. I think that most of the 
names are pretty clear and inform about the place in the architectural 
layers. However, I think that it can be improved by following a pattern 
like:

1 - jackrabbit-[ext name] pattern for jackrabbit specific extensions
2 - jcr-[tool name] pattern for applications built on top of JCR
3 - [lang name]-cr pattern for ports to another languages

I'd prefer a flat structure under /subprojects and under 
/subprojects/sandbox, I think that clear names and documentation in the 
site should give enough information to newcomers.

BR,
edgar

[1] quote "The purpose of this incubation period is ... to allow the 
developers to focus on this interface/implementation rather than all of 
the existing projects that might want to use it..."

Jukka Zitting wrote:
> 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
> 
> 
> 

Mime
View raw message