You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Carsten Ziegeler <cz...@apache.org> on 2012/06/10 17:19:21 UTC
[VOTE] Moving SLING-2396 to trunk
Hi,
I really would like to move forward with SLING-2396 (Make
ResourceResolverFactory independent from JCR) in order to implement
other features (like CRUD support for the resource resolver) on top of
this.
Unfortunately this change introduces an incompatibility wrt
workspaces, therefore I thought it's safer to call a vote and see what
the community things about it.
The vote is not about implementing SLING-2396 in exactly the way it is
right now, its just to move the code to trunk and continue to work
there.
For the workspace support, right now, it's possible to address other
workspaces by specifying an artificial path {workspacename}:{/path} .
This won't be possible anymore, however it would be possible to mount
a workspace at any path in the resource tree (and that would happen on
demand).
I think, if someone really needs the special path access to a
workspace like it is today, then we could add a wrapper for the
resource resolver which does this special logic in the wrapper.
However, if we don't need it, i don't want to spent time on that :)
I think SLING-2396 is one of the most important changes to our code
base, which will make it easier to implement new features in the
resource resolving area, e.g. we get adding different search providers
for free etc.
Please vote, thanks :)
Regards
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: [VOTE] Moving SLING-2396 to trunk
Posted by Carsten Ziegeler <cz...@apache.org>.
+1
Carsten
2012/6/12 Felix Meschberger <fm...@adobe.com>:
> Same here
>
> +1
>
> Thanks and Regards
> Felix
>
> Am 11.06.2012 um 09:53 schrieb Mike Müller:
>
>> Hi Carsten
>>
>> Thank you for bringing up this again.
>> A think this major change could bring Sling a lot forward and
>> maybe gives us the chance to get a broader user base.
>> And making things independent from each other is a good
>> idea anyway ;-)
>>
>> so, a big +1
>>
>> best regards
>> mike
>>
>>> -----Original Message-----
>>> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
>>> Sent: Sunday, June 10, 2012 5:19 PM
>>> To: dev@sling.apache.org
>>> Subject: [VOTE] Moving SLING-2396 to trunk
>>>
>>> Hi,
>>>
>>> I really would like to move forward with SLING-2396 (Make
>>> ResourceResolverFactory independent from JCR) in order to implement
>>> other features (like CRUD support for the resource resolver) on top of
>>> this.
>>>
>>> Unfortunately this change introduces an incompatibility wrt
>>> workspaces, therefore I thought it's safer to call a vote and see what
>>> the community things about it.
>>> The vote is not about implementing SLING-2396 in exactly the way it is
>>> right now, its just to move the code to trunk and continue to work
>>> there.
>>>
>>> For the workspace support, right now, it's possible to address other
>>> workspaces by specifying an artificial path {workspacename}:{/path} .
>>> This won't be possible anymore, however it would be possible to mount
>>> a workspace at any path in the resource tree (and that would happen on
>>> demand).
>>>
>>> I think, if someone really needs the special path access to a
>>> workspace like it is today, then we could add a wrapper for the
>>> resource resolver which does this special logic in the wrapper.
>>> However, if we don't need it, i don't want to spent time on that :)
>>>
>>> I think SLING-2396 is one of the most important changes to our code
>>> base, which will make it easier to implement new features in the
>>> resource resolving area, e.g. we get adding different search providers
>>> for free etc.
>>>
>>> Please vote, thanks :)
>>>
>>> Regards
>>> Carsten
>>> --
>>> Carsten Ziegeler
>>> cziegeler@apache.org
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [VOTE] Moving SLING-2396 to trunk
Posted by Felix Meschberger <fm...@adobe.com>.
Same here
+1
Thanks and Regards
Felix
Am 11.06.2012 um 09:53 schrieb Mike Müller:
> Hi Carsten
>
> Thank you for bringing up this again.
> A think this major change could bring Sling a lot forward and
> maybe gives us the chance to get a broader user base.
> And making things independent from each other is a good
> idea anyway ;-)
>
> so, a big +1
>
> best regards
> mike
>
>> -----Original Message-----
>> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
>> Sent: Sunday, June 10, 2012 5:19 PM
>> To: dev@sling.apache.org
>> Subject: [VOTE] Moving SLING-2396 to trunk
>>
>> Hi,
>>
>> I really would like to move forward with SLING-2396 (Make
>> ResourceResolverFactory independent from JCR) in order to implement
>> other features (like CRUD support for the resource resolver) on top of
>> this.
>>
>> Unfortunately this change introduces an incompatibility wrt
>> workspaces, therefore I thought it's safer to call a vote and see what
>> the community things about it.
>> The vote is not about implementing SLING-2396 in exactly the way it is
>> right now, its just to move the code to trunk and continue to work
>> there.
>>
>> For the workspace support, right now, it's possible to address other
>> workspaces by specifying an artificial path {workspacename}:{/path} .
>> This won't be possible anymore, however it would be possible to mount
>> a workspace at any path in the resource tree (and that would happen on
>> demand).
>>
>> I think, if someone really needs the special path access to a
>> workspace like it is today, then we could add a wrapper for the
>> resource resolver which does this special logic in the wrapper.
>> However, if we don't need it, i don't want to spent time on that :)
>>
>> I think SLING-2396 is one of the most important changes to our code
>> base, which will make it easier to implement new features in the
>> resource resolving area, e.g. we get adding different search providers
>> for free etc.
>>
>> Please vote, thanks :)
>>
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org
RE: [VOTE] Moving SLING-2396 to trunk
Posted by Mike Müller <mi...@mysign.ch>.
Hi Carsten
Thank you for bringing up this again.
A think this major change could bring Sling a lot forward and
maybe gives us the chance to get a broader user base.
And making things independent from each other is a good
idea anyway ;-)
so, a big +1
best regards
mike
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
> Sent: Sunday, June 10, 2012 5:19 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Moving SLING-2396 to trunk
>
> Hi,
>
> I really would like to move forward with SLING-2396 (Make
> ResourceResolverFactory independent from JCR) in order to implement
> other features (like CRUD support for the resource resolver) on top of
> this.
>
> Unfortunately this change introduces an incompatibility wrt
> workspaces, therefore I thought it's safer to call a vote and see what
> the community things about it.
> The vote is not about implementing SLING-2396 in exactly the way it is
> right now, its just to move the code to trunk and continue to work
> there.
>
> For the workspace support, right now, it's possible to address other
> workspaces by specifying an artificial path {workspacename}:{/path} .
> This won't be possible anymore, however it would be possible to mount
> a workspace at any path in the resource tree (and that would happen on
> demand).
>
> I think, if someone really needs the special path access to a
> workspace like it is today, then we could add a wrapper for the
> resource resolver which does this special logic in the wrapper.
> However, if we don't need it, i don't want to spent time on that :)
>
> I think SLING-2396 is one of the most important changes to our code
> base, which will make it easier to implement new features in the
> resource resolving area, e.g. we get adding different search providers
> for free etc.
>
> Please vote, thanks :)
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: [VOTE] Moving SLING-2396 to trunk
Posted by Pontus Amberg <po...@comhem.se>.
Should the relativePath of parent really be "../../../parent/pom.xml" ?
Shouldn't it be "../../parent/pom.xml" ?
/Pontus
On 2012-06-14 13:01, Carsten Ziegeler wrote:
> Thanks everyone - I've committed all the changes to trunk.
>
> So far noone complaint about missing workspace support... :)
>
> Regards
> Carsten
>
> 2012/6/12 Ian Boston<ie...@tfd.co.uk>:
>> Hi,
>> Not using workspaces to any great extent I have to be +1 on this as it
>> makes integration of other sources possible without changes to the
>> core Jackrabbit bundle, however I would like to hear how disruptive it
>> really is for those using workspaces in a more traditional content
>> management mode.
>>
>> Ian
>>
>> BTW, thanks for the work, nice.
>>
>> On 12 June 2012 04:10, Vidar Ramdal<vi...@webstep.no> wrote:
>>> 2012/6/10 Carsten Ziegeler<cz...@apache.org>:
>>>> I really would like to move forward with SLING-2396 (Make
>>>> ResourceResolverFactory independent from JCR) in order to implement
>>>> other features (like CRUD support for the resource resolver) on top of
>>>> this.
>>>>
>>>> Unfortunately this change introduces an incompatibility wrt
>>>> workspaces, therefore I thought it's safer to call a vote and see what
>>>> the community things about it.
>>>> The vote is not about implementing SLING-2396 in exactly the way it is
>>>> right now, its just to move the code to trunk and continue to work
>>>> there.
>>>>
>>>> For the workspace support, right now, it's possible to address other
>>>> workspaces by specifying an artificial path {workspacename}:{/path} .
>>>> This won't be possible anymore, however it would be possible to mount
>>>> a workspace at any path in the resource tree (and that would happen on
>>>> demand).
>>>>
>>>> I think, if someone really needs the special path access to a
>>>> workspace like it is today, then we could add a wrapper for the
>>>> resource resolver which does this special logic in the wrapper.
>>>> However, if we don't need it, i don't want to spent time on that :)
>>>>
>>>> I think SLING-2396 is one of the most important changes to our code
>>>> base, which will make it easier to implement new features in the
>>>> resource resolving area, e.g. we get adding different search providers
>>>> for free etc.
>>>>
>>>> Please vote, thanks :)
>>> +1
>>>
>>> This is so cool in a million ways!
>>>
>>>
>>> --
>>> Vidar S. Ramdal<vi...@webstep.no>
>>> Webstep AS - http://www.webstep.no
>>> Besøksadresse: Lilleakerveien 8, 0283 Oslo
>>> Postadresse: Postboks 272 Lilleaker, 0216 Oslo
>
>
Re: [VOTE] Moving SLING-2396 to trunk
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 14.06.2012 um 08:13 schrieb Carsten Ziegeler:
> Hi Justin,
>
> no, it isn't, I removed the whole workspace support. But this could be
> re-added if required.
We should maybe have an issue to track this. IIRC support for logging into a non-default workspace for a request is trivial.
Regards
Felix
> However resources would not have the workspace
> name prefixed in the path anymore.
>
> Regards
> Carsten
>
> 2012/6/14 Justin Edelson <ju...@gmail.com>:
>> Hi Carsten,
>> I did not have a chance to review the code - been a busy week. One question - is the ability to select a non-default workspace on login still present?
>>
>> Justin
>>
>> On Jun 14, 2012, at 7:01 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>
>>> Thanks everyone - I've committed all the changes to trunk.
>>>
>>> So far noone complaint about missing workspace support... :)
>>>
>>> Regards
>>> Carsten
>>>
>>> 2012/6/12 Ian Boston <ie...@tfd.co.uk>:
>>>> Hi,
>>>> Not using workspaces to any great extent I have to be +1 on this as it
>>>> makes integration of other sources possible without changes to the
>>>> core Jackrabbit bundle, however I would like to hear how disruptive it
>>>> really is for those using workspaces in a more traditional content
>>>> management mode.
>>>>
>>>> Ian
>>>>
>>>> BTW, thanks for the work, nice.
>>>>
>>>> On 12 June 2012 04:10, Vidar Ramdal <vi...@webstep.no> wrote:
>>>>> 2012/6/10 Carsten Ziegeler <cz...@apache.org>:
>>>>>> I really would like to move forward with SLING-2396 (Make
>>>>>> ResourceResolverFactory independent from JCR) in order to implement
>>>>>> other features (like CRUD support for the resource resolver) on top of
>>>>>> this.
>>>>>>
>>>>>> Unfortunately this change introduces an incompatibility wrt
>>>>>> workspaces, therefore I thought it's safer to call a vote and see what
>>>>>> the community things about it.
>>>>>> The vote is not about implementing SLING-2396 in exactly the way it is
>>>>>> right now, its just to move the code to trunk and continue to work
>>>>>> there.
>>>>>>
>>>>>> For the workspace support, right now, it's possible to address other
>>>>>> workspaces by specifying an artificial path {workspacename}:{/path} .
>>>>>> This won't be possible anymore, however it would be possible to mount
>>>>>> a workspace at any path in the resource tree (and that would happen on
>>>>>> demand).
>>>>>>
>>>>>> I think, if someone really needs the special path access to a
>>>>>> workspace like it is today, then we could add a wrapper for the
>>>>>> resource resolver which does this special logic in the wrapper.
>>>>>> However, if we don't need it, i don't want to spent time on that :)
>>>>>>
>>>>>> I think SLING-2396 is one of the most important changes to our code
>>>>>> base, which will make it easier to implement new features in the
>>>>>> resource resolving area, e.g. we get adding different search providers
>>>>>> for free etc.
>>>>>>
>>>>>> Please vote, thanks :)
>>>>>
>>>>> +1
>>>>>
>>>>> This is so cool in a million ways!
>>>>>
>>>>>
>>>>> --
>>>>> Vidar S. Ramdal <vi...@webstep.no>
>>>>> Webstep AS - http://www.webstep.no
>>>>> Besøksadresse: Lilleakerveien 8, 0283 Oslo
>>>>> Postadresse: Postboks 272 Lilleaker, 0216 Oslo
>>>
>>>
>>>
>>> --
>>> Carsten Ziegeler
>>> cziegeler@apache.org
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: [VOTE] Moving SLING-2396 to trunk
Posted by Carsten Ziegeler <cz...@apache.org>.
Coming back to the workspace support, which part do you think should
be available? Specifying the workspace through a request attribute or
as a value inside the authentication map?
Regards
Carsten
2012/6/14 Carsten Ziegeler <cz...@apache.org>:
> Hi Justin,
>
> no, it isn't, I removed the whole workspace support. But this could be
> re-added if required. However resources would not have the workspace
> name prefixed in the path anymore.
>
> Regards
> Carsten
>
> 2012/6/14 Justin Edelson <ju...@gmail.com>:
>> Hi Carsten,
>> I did not have a chance to review the code - been a busy week. One question - is the ability to select a non-default workspace on login still present?
>>
>> Justin
>>
>> On Jun 14, 2012, at 7:01 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>
>>> Thanks everyone - I've committed all the changes to trunk.
>>>
>>> So far noone complaint about missing workspace support... :)
>>>
>>> Regards
>>> Carsten
>>>
>>> 2012/6/12 Ian Boston <ie...@tfd.co.uk>:
>>>> Hi,
>>>> Not using workspaces to any great extent I have to be +1 on this as it
>>>> makes integration of other sources possible without changes to the
>>>> core Jackrabbit bundle, however I would like to hear how disruptive it
>>>> really is for those using workspaces in a more traditional content
>>>> management mode.
>>>>
>>>> Ian
>>>>
>>>> BTW, thanks for the work, nice.
>>>>
>>>> On 12 June 2012 04:10, Vidar Ramdal <vi...@webstep.no> wrote:
>>>>> 2012/6/10 Carsten Ziegeler <cz...@apache.org>:
>>>>>> I really would like to move forward with SLING-2396 (Make
>>>>>> ResourceResolverFactory independent from JCR) in order to implement
>>>>>> other features (like CRUD support for the resource resolver) on top of
>>>>>> this.
>>>>>>
>>>>>> Unfortunately this change introduces an incompatibility wrt
>>>>>> workspaces, therefore I thought it's safer to call a vote and see what
>>>>>> the community things about it.
>>>>>> The vote is not about implementing SLING-2396 in exactly the way it is
>>>>>> right now, its just to move the code to trunk and continue to work
>>>>>> there.
>>>>>>
>>>>>> For the workspace support, right now, it's possible to address other
>>>>>> workspaces by specifying an artificial path {workspacename}:{/path} .
>>>>>> This won't be possible anymore, however it would be possible to mount
>>>>>> a workspace at any path in the resource tree (and that would happen on
>>>>>> demand).
>>>>>>
>>>>>> I think, if someone really needs the special path access to a
>>>>>> workspace like it is today, then we could add a wrapper for the
>>>>>> resource resolver which does this special logic in the wrapper.
>>>>>> However, if we don't need it, i don't want to spent time on that :)
>>>>>>
>>>>>> I think SLING-2396 is one of the most important changes to our code
>>>>>> base, which will make it easier to implement new features in the
>>>>>> resource resolving area, e.g. we get adding different search providers
>>>>>> for free etc.
>>>>>>
>>>>>> Please vote, thanks :)
>>>>>
>>>>> +1
>>>>>
>>>>> This is so cool in a million ways!
>>>>>
>>>>>
>>>>> --
>>>>> Vidar S. Ramdal <vi...@webstep.no>
>>>>> Webstep AS - http://www.webstep.no
>>>>> Besøksadresse: Lilleakerveien 8, 0283 Oslo
>>>>> Postadresse: Postboks 272 Lilleaker, 0216 Oslo
>>>
>>>
>>>
>>> --
>>> Carsten Ziegeler
>>> cziegeler@apache.org
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
--
Carsten Ziegeler
cziegeler@apache.org
Re: [VOTE] Moving SLING-2396 to trunk
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi Justin,
no, it isn't, I removed the whole workspace support. But this could be
re-added if required. However resources would not have the workspace
name prefixed in the path anymore.
Regards
Carsten
2012/6/14 Justin Edelson <ju...@gmail.com>:
> Hi Carsten,
> I did not have a chance to review the code - been a busy week. One question - is the ability to select a non-default workspace on login still present?
>
> Justin
>
> On Jun 14, 2012, at 7:01 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>
>> Thanks everyone - I've committed all the changes to trunk.
>>
>> So far noone complaint about missing workspace support... :)
>>
>> Regards
>> Carsten
>>
>> 2012/6/12 Ian Boston <ie...@tfd.co.uk>:
>>> Hi,
>>> Not using workspaces to any great extent I have to be +1 on this as it
>>> makes integration of other sources possible without changes to the
>>> core Jackrabbit bundle, however I would like to hear how disruptive it
>>> really is for those using workspaces in a more traditional content
>>> management mode.
>>>
>>> Ian
>>>
>>> BTW, thanks for the work, nice.
>>>
>>> On 12 June 2012 04:10, Vidar Ramdal <vi...@webstep.no> wrote:
>>>> 2012/6/10 Carsten Ziegeler <cz...@apache.org>:
>>>>> I really would like to move forward with SLING-2396 (Make
>>>>> ResourceResolverFactory independent from JCR) in order to implement
>>>>> other features (like CRUD support for the resource resolver) on top of
>>>>> this.
>>>>>
>>>>> Unfortunately this change introduces an incompatibility wrt
>>>>> workspaces, therefore I thought it's safer to call a vote and see what
>>>>> the community things about it.
>>>>> The vote is not about implementing SLING-2396 in exactly the way it is
>>>>> right now, its just to move the code to trunk and continue to work
>>>>> there.
>>>>>
>>>>> For the workspace support, right now, it's possible to address other
>>>>> workspaces by specifying an artificial path {workspacename}:{/path} .
>>>>> This won't be possible anymore, however it would be possible to mount
>>>>> a workspace at any path in the resource tree (and that would happen on
>>>>> demand).
>>>>>
>>>>> I think, if someone really needs the special path access to a
>>>>> workspace like it is today, then we could add a wrapper for the
>>>>> resource resolver which does this special logic in the wrapper.
>>>>> However, if we don't need it, i don't want to spent time on that :)
>>>>>
>>>>> I think SLING-2396 is one of the most important changes to our code
>>>>> base, which will make it easier to implement new features in the
>>>>> resource resolving area, e.g. we get adding different search providers
>>>>> for free etc.
>>>>>
>>>>> Please vote, thanks :)
>>>>
>>>> +1
>>>>
>>>> This is so cool in a million ways!
>>>>
>>>>
>>>> --
>>>> Vidar S. Ramdal <vi...@webstep.no>
>>>> Webstep AS - http://www.webstep.no
>>>> Besøksadresse: Lilleakerveien 8, 0283 Oslo
>>>> Postadresse: Postboks 272 Lilleaker, 0216 Oslo
>>
>>
>>
>> --
>> Carsten Ziegeler
>> cziegeler@apache.org
--
Carsten Ziegeler
cziegeler@apache.org
Re: [VOTE] Moving SLING-2396 to trunk
Posted by Justin Edelson <ju...@gmail.com>.
Hi Carsten,
I did not have a chance to review the code - been a busy week. One question - is the ability to select a non-default workspace on login still present?
Justin
On Jun 14, 2012, at 7:01 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Thanks everyone - I've committed all the changes to trunk.
>
> So far noone complaint about missing workspace support... :)
>
> Regards
> Carsten
>
> 2012/6/12 Ian Boston <ie...@tfd.co.uk>:
>> Hi,
>> Not using workspaces to any great extent I have to be +1 on this as it
>> makes integration of other sources possible without changes to the
>> core Jackrabbit bundle, however I would like to hear how disruptive it
>> really is for those using workspaces in a more traditional content
>> management mode.
>>
>> Ian
>>
>> BTW, thanks for the work, nice.
>>
>> On 12 June 2012 04:10, Vidar Ramdal <vi...@webstep.no> wrote:
>>> 2012/6/10 Carsten Ziegeler <cz...@apache.org>:
>>>> I really would like to move forward with SLING-2396 (Make
>>>> ResourceResolverFactory independent from JCR) in order to implement
>>>> other features (like CRUD support for the resource resolver) on top of
>>>> this.
>>>>
>>>> Unfortunately this change introduces an incompatibility wrt
>>>> workspaces, therefore I thought it's safer to call a vote and see what
>>>> the community things about it.
>>>> The vote is not about implementing SLING-2396 in exactly the way it is
>>>> right now, its just to move the code to trunk and continue to work
>>>> there.
>>>>
>>>> For the workspace support, right now, it's possible to address other
>>>> workspaces by specifying an artificial path {workspacename}:{/path} .
>>>> This won't be possible anymore, however it would be possible to mount
>>>> a workspace at any path in the resource tree (and that would happen on
>>>> demand).
>>>>
>>>> I think, if someone really needs the special path access to a
>>>> workspace like it is today, then we could add a wrapper for the
>>>> resource resolver which does this special logic in the wrapper.
>>>> However, if we don't need it, i don't want to spent time on that :)
>>>>
>>>> I think SLING-2396 is one of the most important changes to our code
>>>> base, which will make it easier to implement new features in the
>>>> resource resolving area, e.g. we get adding different search providers
>>>> for free etc.
>>>>
>>>> Please vote, thanks :)
>>>
>>> +1
>>>
>>> This is so cool in a million ways!
>>>
>>>
>>> --
>>> Vidar S. Ramdal <vi...@webstep.no>
>>> Webstep AS - http://www.webstep.no
>>> Besøksadresse: Lilleakerveien 8, 0283 Oslo
>>> Postadresse: Postboks 272 Lilleaker, 0216 Oslo
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: [VOTE] Moving SLING-2396 to trunk
Posted by Carsten Ziegeler <cz...@apache.org>.
Thanks everyone - I've committed all the changes to trunk.
So far noone complaint about missing workspace support... :)
Regards
Carsten
2012/6/12 Ian Boston <ie...@tfd.co.uk>:
> Hi,
> Not using workspaces to any great extent I have to be +1 on this as it
> makes integration of other sources possible without changes to the
> core Jackrabbit bundle, however I would like to hear how disruptive it
> really is for those using workspaces in a more traditional content
> management mode.
>
> Ian
>
> BTW, thanks for the work, nice.
>
> On 12 June 2012 04:10, Vidar Ramdal <vi...@webstep.no> wrote:
>> 2012/6/10 Carsten Ziegeler <cz...@apache.org>:
>>> I really would like to move forward with SLING-2396 (Make
>>> ResourceResolverFactory independent from JCR) in order to implement
>>> other features (like CRUD support for the resource resolver) on top of
>>> this.
>>>
>>> Unfortunately this change introduces an incompatibility wrt
>>> workspaces, therefore I thought it's safer to call a vote and see what
>>> the community things about it.
>>> The vote is not about implementing SLING-2396 in exactly the way it is
>>> right now, its just to move the code to trunk and continue to work
>>> there.
>>>
>>> For the workspace support, right now, it's possible to address other
>>> workspaces by specifying an artificial path {workspacename}:{/path} .
>>> This won't be possible anymore, however it would be possible to mount
>>> a workspace at any path in the resource tree (and that would happen on
>>> demand).
>>>
>>> I think, if someone really needs the special path access to a
>>> workspace like it is today, then we could add a wrapper for the
>>> resource resolver which does this special logic in the wrapper.
>>> However, if we don't need it, i don't want to spent time on that :)
>>>
>>> I think SLING-2396 is one of the most important changes to our code
>>> base, which will make it easier to implement new features in the
>>> resource resolving area, e.g. we get adding different search providers
>>> for free etc.
>>>
>>> Please vote, thanks :)
>>
>> +1
>>
>> This is so cool in a million ways!
>>
>>
>> --
>> Vidar S. Ramdal <vi...@webstep.no>
>> Webstep AS - http://www.webstep.no
>> Besøksadresse: Lilleakerveien 8, 0283 Oslo
>> Postadresse: Postboks 272 Lilleaker, 0216 Oslo
--
Carsten Ziegeler
cziegeler@apache.org
Re: [VOTE] Moving SLING-2396 to trunk
Posted by Ian Boston <ie...@tfd.co.uk>.
Hi,
Not using workspaces to any great extent I have to be +1 on this as it
makes integration of other sources possible without changes to the
core Jackrabbit bundle, however I would like to hear how disruptive it
really is for those using workspaces in a more traditional content
management mode.
Ian
BTW, thanks for the work, nice.
On 12 June 2012 04:10, Vidar Ramdal <vi...@webstep.no> wrote:
> 2012/6/10 Carsten Ziegeler <cz...@apache.org>:
>> I really would like to move forward with SLING-2396 (Make
>> ResourceResolverFactory independent from JCR) in order to implement
>> other features (like CRUD support for the resource resolver) on top of
>> this.
>>
>> Unfortunately this change introduces an incompatibility wrt
>> workspaces, therefore I thought it's safer to call a vote and see what
>> the community things about it.
>> The vote is not about implementing SLING-2396 in exactly the way it is
>> right now, its just to move the code to trunk and continue to work
>> there.
>>
>> For the workspace support, right now, it's possible to address other
>> workspaces by specifying an artificial path {workspacename}:{/path} .
>> This won't be possible anymore, however it would be possible to mount
>> a workspace at any path in the resource tree (and that would happen on
>> demand).
>>
>> I think, if someone really needs the special path access to a
>> workspace like it is today, then we could add a wrapper for the
>> resource resolver which does this special logic in the wrapper.
>> However, if we don't need it, i don't want to spent time on that :)
>>
>> I think SLING-2396 is one of the most important changes to our code
>> base, which will make it easier to implement new features in the
>> resource resolving area, e.g. we get adding different search providers
>> for free etc.
>>
>> Please vote, thanks :)
>
> +1
>
> This is so cool in a million ways!
>
>
> --
> Vidar S. Ramdal <vi...@webstep.no>
> Webstep AS - http://www.webstep.no
> Besøksadresse: Lilleakerveien 8, 0283 Oslo
> Postadresse: Postboks 272 Lilleaker, 0216 Oslo
Re: [VOTE] Moving SLING-2396 to trunk
Posted by Vidar Ramdal <vi...@webstep.no>.
2012/6/10 Carsten Ziegeler <cz...@apache.org>:
> I really would like to move forward with SLING-2396 (Make
> ResourceResolverFactory independent from JCR) in order to implement
> other features (like CRUD support for the resource resolver) on top of
> this.
>
> Unfortunately this change introduces an incompatibility wrt
> workspaces, therefore I thought it's safer to call a vote and see what
> the community things about it.
> The vote is not about implementing SLING-2396 in exactly the way it is
> right now, its just to move the code to trunk and continue to work
> there.
>
> For the workspace support, right now, it's possible to address other
> workspaces by specifying an artificial path {workspacename}:{/path} .
> This won't be possible anymore, however it would be possible to mount
> a workspace at any path in the resource tree (and that would happen on
> demand).
>
> I think, if someone really needs the special path access to a
> workspace like it is today, then we could add a wrapper for the
> resource resolver which does this special logic in the wrapper.
> However, if we don't need it, i don't want to spent time on that :)
>
> I think SLING-2396 is one of the most important changes to our code
> base, which will make it easier to implement new features in the
> resource resolving area, e.g. we get adding different search providers
> for free etc.
>
> Please vote, thanks :)
+1
This is so cool in a million ways!
--
Vidar S. Ramdal <vi...@webstep.no>
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 272 Lilleaker, 0216 Oslo