jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting ...@yukatan.fi>
Subject Re: build problems
Date Mon, 11 Jul 2005 12:31:42 GMT
Hi,

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.

> 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.

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.

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.

> 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.

How about adopting the proposed directory structure you proposed but 
keeping the existing component names?

BR,

Jukka Zitting


Mime
View raw message