On Tue, Dec 2, 2008 at 4:52 PM, Jukka Zitting <[EMAIL PROTECTED]> wrote:
>
> COMPONENTS
>
> The JCR Commons subproject would take over the development and
> maintenance of the following components:
>
> * jackrabbit-jcr-commons
> * jackrabbit-jcr-tests
> * jackrabbit-jcr-benchmark
> * jackrabbit-jcr-rmi
> * jackrabbit-jcr-servlet
> * jackrabbit-webdav
> * jackrabbit-jcr-server
> * jackrabbit-classloader
> * jackrabbit-ocm
> * jackrabbit-ocm-nodemanagement
Do all these projects solely rely on the JCR API? They shouldn't be
dependent on anything from core (or the deployment packages + the SPI
stuff), because - as the core already depends on some of them, eg.
jcr-commons - we would have circular dependencies. I don't have an
overview of the dependencies at the moment, that's why I am asking.
This clear separation should be the guide for everything in the
commons subproject.
> INFRASTRUCTURE
>
> * Mailing lists: We create the following new mailing lists for the
> subproject: commons-{user,dev,[EMAIL PROTECTED] Again,
> following the example of Apache Commons in how to organize the mailing
> lists (for example use a [rmi] subject prefix for all messages
> regarding JCR-RMI) is probably a good idea.
Not sure if we should create more mailing lists, as many mailing lists
make it difficult for beginners to get a start ("which one shall I
subscribe to for a quick question?"). Maybe we can re-use the existing
ones and work with the mentioned "[commons-rmi]" prefix there.
If we have separate svn trunks and a separate jira project, this would
be kind of a mismatch, but I suggest that in the beginning we should
"force" people to cross-talk on commons and core. Only if commons
becomes active on its own, we could separate the lists as well. WDYT?
Otherwise my ACK to all other points!
Regards,
Alex
--
Alexander Klimetschek
[EMAIL PROTECTED]
