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: build problems
Date Mon, 11 Jul 2005 15:20:46 GMT
On Jul 11, 2005, at 5:31 AM, Jukka Zitting wrote:

> Roy T. Fielding wrote:
>> I am going to disagree a little bit.  We need to figure out what
>> will be included in an eventual 1.0 release and build all of it.
>
> I'd prefer to keep the project scope limited to "Implementation of the 
> Content Repository for Java" as written in the project descriptor. 
> Thus none of the current contrib packages would be included in the 
> release.

I could certainly go along with that, but then why do they exist in
our subversion?  Personally, I don't think we should be managing
code that we don't intend to release sometime.  If their purpose is
to be an example for documentation, then they should be organized
as examples rather than as code dumps.

I think the bulk of that code is intended as either deployment
methods or examples for reducing the chicken-and-egg problem:
encouraging applications to build stuff on top of JCR while at
the same time exploring various use-cases for JCR.  However,
I have no clue where the phpcr stuff belongs, so we do need a
sandbox of some kind for now until things like that can move
to their own incubator project.

>> Also, I don't believe Apache should have visible subprojects.
>> Projects have a habit of forgetting that they are responsible
>> for the entire contents of version control and subprojects
>> get twisted into fiefdoms.
>
> I see the point. However I don't think it would be wise to widen the 
> stated project scope into "Various stuff related to JCR". Some 
> thoughts about this:
>
> Currently I think the Jackrabbit *community scope* as significantly 
> wider than the Jackrabbit *project scope*. As discussed six months 
> ago, the Jackrabbit community is forming up to be a central place for 
> things related to JCR. If JCR lives up to its potential, I can 
> envision a need for a  top level Apache JCR project like the existing 
> DB, logging, XML, and WS projects. In that sense I think the concept 
> of subprojects fits our needs very well.

Jackrabbit needs to have one scope and that is managing the code
that it intends to release.  This project is already heading to TLP
status after incubation, with similar scope to the APR project.
Umbrella projects like Jakarta, DB, XML, and WS are things of
the past -- they are gradually separating into smaller, sustainable
projects, leaving the umbrellas only responsible for commons code and
shared interfaces/documentation.  I am not a big fan of communities
that are larger than projects, since they don't do a very good job
of quality control.

> But it is clear that such progress is just starting and that at the 
> moment there certainly isn't enough interest for example to split 
> JCR-RMI into a self-contained project with its own community. I think 
> it would be quite interesting and helpful to learn from similar cases 
> in the Apache history.

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.  Likewise, the
directory structure should lead the code base towards plug-in
persistence managers, since that is an obvious extensibility point.
Most of the other things in contrib are simply thrown there with
no rhyme or reason, interfering with comprehension of the project.

> Of course it would be possible to solve this issue by declaring 
> components like JCR-RMI  parts of the Jackrabbit implementation that 
> just happen to have only general JCR dependencies. This might be a 
> reasonable short term solution, but in the long run I'd prefer to 
> manage such cleanly scoped components as independent subprojects with 
> separate release schedules etc.

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.

>> So, for those reasons, I would prefer
>
> 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.

....Roy


Mime
View raw message