Hi all, Thanks for your replies.
Here is a consolidated view of the replies with respect to my proposal Felix Meschberger schrieb: > bundles/jcr/api > Provides the SlingRepository iterface. This bundle just > depends on JCR and has no Jackrabbit dependencies. > --> Keep it here ==> We keep it (maybe, depending on how we offer the Jackrabbit-Server and Jackrabbit-Client bundles....) > bundles/jcr/base > Provides an abstract base implementation of the SlingRepository > interface and has Jackrabbit dependencies. > --> Investigate separation of Jackrabbit specific and generic > JCR parts and split the bundle in two: The Jackrabbit part goes > to Jackrabbit, the JCR-only part remains here ==> Investigate further... Potentially donate to Jackrabbit. > bundles/jcr/classloader > Depends on the Jackrabbit JCR Classloader but extends it for > some Sling specific parts. > --> Keep it here ==> Keep it and even continue on Jukka's proposal of migrating the class loader core from Jackrabbit to Sling. > bundles/jcr/contentloader > Initial Content Loader, currently has dependency on Jackrabbit > API for ACL stuff. For JCR 2.0 this will be converted into a > pure JCR 2.0 dependency, hence be completely independent of > Jackrabbit > --> Keep it or offer to Jackrabbit ? ==> We keep it > bundles/jcr/jackrabbit-accessmanager > Access Control Management servlets leveraging Sling > functionality. > --> Keep it here ==> We keep it > bundles/jcr/jackrabbit-usermanager > User Manager for Jackrabbit (might be converted into a generic > JCR 2.0 user manager ?) leveraging Sling functionality. > --> Keep it here ==> We keep it > > bundles/jcr/jackrabbit-server > Embedded Jackrabbit Repository providing Service API to plugin > LoginModules as OSGi services. > --> Offer to Jackrabbit ==> Offer to Jackrabbit, but decide on "how" -- the most important question is to ensure our extensions and to even go a step further and support Ian's requirement for fully flexible access control plugin (not requiring to extend DefaultAccessManager) > bundles/jcr/ocm > OSGi bundle with Jackrabbit-OCM providing a Sling > AdapterFactory for resources. Plugs heavily into Sling. > --> Keep it here or offer to Jackrabbit ? ==> We keep it > bundles/jcr/resource > JCRResourceResolver > --> We keep this ;-) ==> Well, of course, we keep it. This is part of our crown jewels ;-) > bundles/jcr/webdav > (Simple) WebDAV servlet(s) > --> Offer to Jackrabbit ==> Offer to Jackrabbit > contrib/jcr/compiler > Compiles Java Classes into the Repository. This is part of > Sling. > --> Keep it here ==> We keep it > contrib/jcr/jackrabbit-api > Old OSGi bundle wrapping of Jackrabbit API. This is not used > any longer, since Jackrabbit already provides OSGi bundles of > some libraries, including the Jackrabbit API > --> Deprecate and remove sometime in the future (move to "attic"?) ==> Removing > contrib/jcr/jackrabbit-client > Provides access to non-embedded repositories, mostly Jackrabbit > oriented. > --> Offer to Jackrabbit == Offer to Jackrabbit > contrib/jcr/prefs > JCR bindings for the Apache Felix OSGi Preferences Service > implementation. > --> Keep it here ==> We keep it I will follow up in separate threads with thoughts about what to offer to Jackrabbit and how. I have also prepared a Wiki page for these issues [1] Regards Felix [1] http://cwiki.apache.org/SLING/donating-jackrabbit-integration-to-apache-jackrabbit.html
