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 2016/02/12 07:50:29 UTC
[RT] Deprecating the jcr resource API
Hi,
I think we should deprecate the jcr resource API completely, most of it
is already deprecated. Deprecating will allow us to get rid of it in the
future and reduce the parts we have to maintain.
Most of that API is very old and was created in a time where we didn't
have CRUD support for resources. Now that we have this for some time,
there shouldn't be a need for any of this API. And if so, jackrabbit
would be a much better place.
Right now, we still have not deprecated:
JcrResourceUtil#query - Resource Resolver should be used instead.
JcrResourceUtil#toJavaObject - Value Map should be used instead.
JcrResourceUtil#createValue - Modifiable Value Map should be used instead.
JcrResourceUtil#setProperty - Modifiable Value Map should be used instead.
JcrResourceUtil#createPath - ResourceUtil#getOrCreateResource should be
used instead
This leaves us with some constants in JcrResourceConstants. Although I
would love to get rid of them to not have any API at all in the jcr
resource bundle, some of them are really related to the jcr resource
provider.
If no one objects, I'll deprecated JcrResourceUtil completely.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [RT] Deprecating the jcr resource API
Posted by Konrad Windszus <ko...@gmx.de>.
+1 on deprecating this class.
> On 12 Feb 2016, at 07:50, Carsten Ziegeler <cz...@apache.org> wrote:
>
> Hi,
>
> I think we should deprecate the jcr resource API completely, most of it
> is already deprecated. Deprecating will allow us to get rid of it in the
> future and reduce the parts we have to maintain.
>
> Most of that API is very old and was created in a time where we didn't
> have CRUD support for resources. Now that we have this for some time,
> there shouldn't be a need for any of this API. And if so, jackrabbit
> would be a much better place.
>
> Right now, we still have not deprecated:
> JcrResourceUtil#query - Resource Resolver should be used instead.
> JcrResourceUtil#toJavaObject - Value Map should be used instead.
> JcrResourceUtil#createValue - Modifiable Value Map should be used instead.
> JcrResourceUtil#setProperty - Modifiable Value Map should be used instead.
> JcrResourceUtil#createPath - ResourceUtil#getOrCreateResource should be
> used instead
>
> This leaves us with some constants in JcrResourceConstants. Although I
> would love to get rid of them to not have any API at all in the jcr
> resource bundle, some of them are really related to the jcr resource
> provider.
>
> If no one objects, I'll deprecated JcrResourceUtil completely.
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
Re: [RT] Deprecating the jcr resource API
Posted by Carsten Ziegeler <cz...@apache.org>.
Thanks everyone for the feedback, I deprecated the util class
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [RT] Deprecating the jcr resource API
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Friday 12 February 2016 07:50:29 Carsten Ziegeler wrote:
> Hi,
>
> I think we should deprecate the jcr resource API completely, most of it
> is already deprecated. Deprecating will allow us to get rid of it in the
> future and reduce the parts we have to maintain.
>
> Most of that API is very old and was created in a time where we didn't
> have CRUD support for resources. Now that we have this for some time,
> there shouldn't be a need for any of this API. And if so, jackrabbit
> would be a much better place.
>
> Right now, we still have not deprecated:
> JcrResourceUtil#query - Resource Resolver should be used instead.
> JcrResourceUtil#toJavaObject - Value Map should be used instead.
> JcrResourceUtil#createValue - Modifiable Value Map should be used instead.
> JcrResourceUtil#setProperty - Modifiable Value Map should be used instead.
> JcrResourceUtil#createPath - ResourceUtil#getOrCreateResource should be
> used instead
>
> This leaves us with some constants in JcrResourceConstants. Although I
> would love to get rid of them to not have any API at all in the jcr
> resource bundle, some of them are really related to the jcr resource
> provider.
>
> If no one objects, I'll deprecated JcrResourceUtil completely.
+1
O.
> Regards
> Carsten
Re: [RT] Deprecating the jcr resource API
Posted by Antonio Sanso <as...@adobe.com>.
+1 on deprecating
On Feb 12, 2016, at 7:50 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Hi,
>
> I think we should deprecate the jcr resource API completely, most of it
> is already deprecated. Deprecating will allow us to get rid of it in the
> future and reduce the parts we have to maintain.
>
> Most of that API is very old and was created in a time where we didn't
> have CRUD support for resources. Now that we have this for some time,
> there shouldn't be a need for any of this API. And if so, jackrabbit
> would be a much better place.
>
> Right now, we still have not deprecated:
> JcrResourceUtil#query - Resource Resolver should be used instead.
> JcrResourceUtil#toJavaObject - Value Map should be used instead.
> JcrResourceUtil#createValue - Modifiable Value Map should be used instead.
> JcrResourceUtil#setProperty - Modifiable Value Map should be used instead.
> JcrResourceUtil#createPath - ResourceUtil#getOrCreateResource should be
> used instead
>
> This leaves us with some constants in JcrResourceConstants. Although I
> would love to get rid of them to not have any API at all in the jcr
> resource bundle, some of them are really related to the jcr resource
> provider.
>
> If no one objects, I'll deprecated JcrResourceUtil completely.
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org