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
