You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Ian Boston <ie...@tfd.co.uk> on 2009/04/30 18:59:39 UTC
JCR2 upgrade plans ?
Hi,
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?
I am trying to plan where I should be directing internal and community
effort in Sakai being just about ready to commit whole heartedly to
the JR15/Sling DefaultAccessManager and other core parts.
Thanks
Ian
Re: JCR2 upgrade plans ?
Posted by Ian Boston <ie...@tfd.co.uk>.
Jukka,
Do you think that the DefaultAccessManager structure will change
greatly from was present in 1.5 trunk?
I am thinking of the storage of acl/ace's in nodes, the ACLProviders/
Editor/Template etc
If this is already fixed in the new 2.0 trunk then just tell me to go
and look :)
Thanks,
Ian
On 1 May 2009, at 23:58, Jukka Zitting wrote:
> Hi,
>
> On Thu, Apr 30, 2009 at 6:59 PM, Ian Boston <ie...@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.
>
> 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
Re: JCR2 upgrade plans ?
Posted by Ian Boston <ie...@tfd.co.uk>.
On 4 May 2009, at 09:37, Vidar Ramdal wrote:
> 2009/5/3 Ian Boston <ie...@tfd.co.uk>
>
>> 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.
>
> But this was done because of the way DefaultAccessManager is linked to
> the rest of the Jackrabbit stuff. If DefaultAccessManager could be
> separated out in a bundle of its own, we would have a pluggable
> accessmanager by definition.
agreed.
Is this likely to happen, as it would also make it much easier to
extend the existing implementation?
Ian
>
>
> --
> Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
> Akersgata 16, N-0158 Oslo, Norway
> +47 21 531941, ext 2070
Re: JCR2 upgrade plans ?
Posted by Vidar Ramdal <vi...@idium.no>.
2009/5/3 Ian Boston <ie...@tfd.co.uk>
> 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.
But this was done because of the way DefaultAccessManager is linked to
the rest of the Jackrabbit stuff. If DefaultAccessManager could be
separated out in a bundle of its own, we would have a pluggable
accessmanager by definition.
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
+47 21 531941, ext 2070
Re: JCR2 upgrade plans ?
Posted by Ian Boston <ie...@tfd.co.uk>.
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 <ie...@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
>>
Re: JCR2 upgrade plans ?
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Sun, May 3, 2009 at 7:10 AM, Felix Meschberger <fm...@gmail.com> wrote:
> In fact, many Jackrabbit libraries already come as bundles
> (jackrabbit-api, jackrabbit-jcr-commons, jackrabbit-jcr-rmi), why not
> the rest also ?
Good question. Patches/commits are welcome. :-)
There's already an issue reported for this
(https://issues.apache.org/jira/browse/JCR-1991), but so far nobody
has had the time or know-how to make this happen. I'd love to have
OSGi metadata included already in Jackrabbit 1.6.
BR,
Jukka Zitting
Re: JCR2 upgrade plans ?
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Mon, May 4, 2009 at 8:29 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> I think that Sling should be able to run on JCR 1.0 for a long time; we
> shouldn't tie us to a new version; however, of course we might have some
> optional functionality requiring JCR 2.0.
>From a functionality perspective JCR 1.0 already covers mostly
everything Sling needs, though there are a few things in JCR 2.0 like
the more flexible node type handling (setPrimaryType!) and improved
query features that may be of interest to Sling.
And regardless of the JCR API version, it probably makes sense for
Sling to upgrade to Jackrabbit 2.x once it's available.
BR,
Jukka Zitting
Re: JCR2 upgrade plans ?
Posted by David Nuescheler <un...@day.com>.
hi guys,
> I think that Sling should be able to run on JCR 1.0 for a long time; we
> shouldn't tie us to a new version; however, of course we might have some
> optional functionality requiring JCR 2.0.
i think we should naturally embrace jcr 2.0, i don't really think that
we will have
backwards compatibility issues since i would not expect that there are other
repositories than jackrabbit that are currently used with sling. so in
my opinion
we should probably use jcr 2.0 where it makes sense particularly over
proprietary
jackrabbit apis as soon as they are available in jackrabbit...
thoughts?
regards,
david
Re: JCR2 upgrade plans ?
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger schrieb:
> Hi,
>
> Jukka Zitting schrieb:
>> Hi,
>>
>> On Thu, Apr 30, 2009 at 6:59 PM, Ian Boston <ie...@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.
>
I think that Sling should be able to run on JCR 1.0 for a long time; we
shouldn't tie us to a new version; however, of course we might have some
optional functionality requiring JCR 2.0.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: JCR2 upgrade plans ?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Jukka Zitting schrieb:
> Hi,
>
> On Thu, Apr 30, 2009 at 6:59 PM, Ian Boston <ie...@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
>
Re: JCR2 upgrade plans ?
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Apr 30, 2009 at 6:59 PM, Ian Boston <ie...@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.
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