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
