I think this may be a question of what is exported from the bundle. At
the moment the jackrabbit-server bundle doesn't expose much more than
the real API's which IMHO is correct, however it does mean that
customizations have to live inside the server bundle. As you say, this
has been done to make the access manager pluggable in trunk Sling.
If the bundles were provided by Jackrabbit, would you want to export
the internal jackrabbit classes?
From a selfish point of view, the modest extensions that were
necessary to make the 283 DefautlAccessManager were only possible with
complete visibility of all of the jackrabbit package space. I could
have done it only having visibility of the API's but that would have
meant a complete re-write, not something I wanted to do.
So, if JR2 is to provide bundles, IMHO some thought should be given to
the API's that are exposed beyond javax.jcr.* *and* critically it
should be possible to make customizations and extensions without re-
writing large areas of functionality or repackaging the bundle. (in a
perfect world with unlimited time :))
Ian
On 3 May 2009, at 06:10, Felix Meschberger wrote:
Hi,
Jukka Zitting schrieb:
Hi,
On Thu, Apr 30, 2009 at 6:59 PM, Ian Boston <i...@tfd.co.uk> wrote:
With JR trunk having branched 1.x off and now heading for 2.0.
What plans, if any does Sling have for moving to 2.0 and 283
support?
With my Jackrabbit release manager hat on I'd recommend that Sling
wait until Jackrabbit 2.0 is officially out before upgrading to JCR
2.0.
I was starting to think on another track: Is it really correct to have
the OSGi bindings for Jackrabbit in the Sling project ?
Wouldn't it be more logical that Jackrabbit would provide the
jackrabbit
binding bundles (jcr/jackrabbit-core and jcr/jackrabbit-client and
probably also jcr/base itself) ?
In fact, many Jackrabbit libraries already come as bundles
(jackrabbit-api, jackrabbit-jcr-commons, jackrabbit-jcr-rmi), why not
the rest also ?
I tend to think, that we might keep the bundles around here at Sling
for
the Jackrabbit 1.x line because we extended Jackrabbit to allow for
pluggable extensions. But for Jackrabbit 2.0 it might be different.
WDYT ?
Regards
Felix
At current rate of things I would expect Jackrabbit 2.0 to be out
sometime within the second half of this year.
BR,
Jukka Zitting
