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
