Re: JCR2 upgrade plans ?
Felix Meschberger schrieb: 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. 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 cziege...@apache.org
Re: JCR2 upgrade plans ?
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 ?
Hi, On Mon, May 4, 2009 at 8:29 AM, Carsten Ziegeler cziege...@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 ?
Hi, On Sun, May 3, 2009 at 7:10 AM, Felix Meschberger fmesc...@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 ?
2009/5/3 Ian Boston i...@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 ?
On 4 May 2009, at 09:37, Vidar Ramdal wrote: 2009/5/3 Ian Boston i...@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 ?
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
Re: JCR2 upgrade plans ?
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
Re: JCR2 upgrade plans ?
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. 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
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
