On 27 Nov 2009, at 13:47, Felix Meschberger wrote:
Hi all,
Right now we have a number of JCR related bundles in Sling. With the
JCR
API 2.0 now public and Jackrabbit runnuning towards its first 2.0
release providing full JCR API 2.0 support, I wonder where we would be
heading with these bundles....
I would like to hear your opinions how to handle the Jackrabbit based
bundles in the future.
I would think some bundles belong to Sling (e.g. the compiler or prefs
bundles). Some bundles would rather belong to the Jackrabbit project.
But then I am not sure about some bundles ....
Here are the bundles I am talking about
bundles/jcr/api
Provides the SlingRepository iterface. This bundle just
depends on JCR and has no Jackrabbit dependencies.
--> Keep it here
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
bundles/jcr/classloader
Depends on the Jackrabbit JCR Classloader but extends it for
some Sling specific parts.
--> Keep it here
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 ?
IMHO, keep, as it binds to OSGi and does things specific to Sling.
bundles/jcr/jackrabbit-accessmanager
Access Control Management servlets leveraging Sling
functionality.
--> Keep it here
bundles/jcr/jackrabbit-server
Embedded Jackrabbit Repository providing Service API to plugin
LoginModules as OSGi services.
--> Offer to Jackrabbit
IMHO, keep this,
There are some aspects of it that are needed for Sling like the plugins.
We might expect JR to create a OSGi Jackrabbit core bundle, but I
think Sling would need to customize it to take care of deployment
issues and local integration points.
I will declare some self interest since this is one of the remaining
bundles that I, with a Sakai hat on, havent been able to avoid
customizing, since the DefaultAccessManager wont cover quite a number
of our use cases and injecting one from a new bundle means writing a
huge amount of very complex code, not something I really want to do.
I am told that the DefaultAccessManager has been re-written for JCR2,
but when I looked at the ACLTemplate and ACLEditor code in svn trunk
it looked quite similar with group deny added (one of our use cases).
So I *am* a bit confused at the moment.
Ian
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
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 ?
bundles/jcr/resource
JCRResourceResolver
--> We keep this ;-)
bundles/jcr/webdav
(Simple) WebDAV servlet(s)
--> Offer to Jackrabbit
contrib/jcr/compiler
Compiles Java Classes into the Repository. This is part of
Sling.
--> Keep it here
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"?)
contrib/jcr/jackrabbit-client
Provides access to non-embedded repositories, mostly
Jackrabbit
oriented.
--> Offer to Jackrabbit
contrib/jcr/prefs
JCR bindings for the Apache Felix OSGi Preferences Service
implementation.
--> Keep it here
I have inlined my opinions with respect to each bundle (marked with
-->).
Please comment. Thanks alot.
Regards
Felix
