You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Karl Pauls <ka...@gmail.com> on 2017/04/25 10:21:01 UTC
move o.a.s.xss.JSONUtil into a separate package
Hi,
as discussed with Stefan Seifert on SLING-6685, we would like to move
the JSONUtil class out of the o.a.s.xss package into a separate sub
package (o.a.s.xss.json).
Right now, it introduces a dependency on the javax.json package for
the o.a.s.xss package. That is the reason we have to bump the version
to 2.0.0 due to the commons.json removable. If we move it into its own
package we wouldn't have to do that if we every switch json providers
again :-).
As we are bumping the major version anyways, I don't think this is a
big deal - hence, I'm calling for lazy consensus (in other words, if
you object, speak up now).
regards,
Karl
--
Karl Pauls
karlpauls@gmail.com
Re: move o.a.s.xss.JSONUtil into a separate package
Posted by Carsten Ziegeler <cz...@apache.org>.
Stefan Seifert wrote
>
>> Do we need this util class in the api at all? (I have no idea, but just
>> asking the obvious question)
>
> perhaps not, but a lot of existing code outside there may use it. and providing an alternative on javax.json is perhaps easier to migrate to than completely removing it.
>
Users have to migrate and they might want to migrate to a different json
library than we suggest. Given the number of choices out there having a
util class for just one is imho not worth the effort.
I think we should agree on whether we want a new json util class first,
then we can look at the versioning problem.
Regards
Carsten
>
>> I understand that for semantic versioning we have to increase the major
>> version of the api. How do we deal with all the code out there currently
>> importing 1.x? Can we find a way that does not require everyone to
>> change her code?
>
> if other classes except JSONUtil are used it's a drop-in replacement, just a recompile against the latest package version is needed (or a relaxed import statement for both major versions). but this still is of course a complex tasks if a lot of bundles depend on the old major version.
>
> we might change the symbolic name of the new xss bundle to allow parallel deployment of old and new implementation.
>
> stefan
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Versioning of o.a.s.xss [was move o.a.s.xss.JSONUtil into a separate package]
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Wednesday 26 April 2017 14:57:26 Konrad Windszus wrote:
> I guess Oliver Lietz meant, changing the symbolic name for the old version
> and keep the symbolic name for the new version, but having both bundles as
> full-fledged independent bundles. That way the dependencies are easier to
> upgrade in the pom.xml.
Sorry for beeing unclear – I really had fragments in mind.
O.
> > On 26. Apr 2017, at 14:47, Carsten Ziegeler <cz...@apache.org> wrote:
> >
> > Oliver Lietz wrote
> >
> >> On Tuesday 25 April 2017 14:09:51 Carsten Ziegeler wrote:
> >>> I'm moving this into a separate thread to make the discussion easier.
> >>>
> >>> With the current state of the xss module, we would break every consumer
> >>> and require her to upgrade code (release their own modules depending on
> >>> XSS etc). As xss is pretty popular, this means a high burden on our
> >>> downstream users.
> >>>
> >>> I think we have these options:
> >>> 1) Pass on the pain to our users, simply release as 2.0.0 and require
> >>> everyone to upgrade
> >>>
> >>> 2) Release the new api as 2.0 under a different symbolic name allowing
> >>> our users to have new and old side by side. In that case we would need
> >>> to deprecate 1.x and users should upgrade over time.
> >>>
> >>> 3) Best effort: we release as 1.x and know that this is an incompatible
> >>> change. This will only break users of the old JSONUtil, everyone else
> >>> runs without any problems. Unfortunately if others are using the util,
> >>> this will only be detected at runtime.
> >>>
> >>> Are the other/better options?
> >>
> >> Can we keep the symbolic name for the new bundle and provide an
> >> additional
> >> compat bundle with old JSONUtil?
> >
> > No, unfortunately not - the JSONUtil is part of the API package. Although
> > it might be possible through a fragment, but I'm unsure what the
> > implications are
> > (if that works at all).
> >
> > Regards
> > Carsten
Re: Versioning of o.a.s.xss [was move o.a.s.xss.JSONUtil into a
separate package]
Posted by Carsten Ziegeler <cz...@apache.org>.
Konrad Windszus wrote
> I guess Oliver Lietz meant, changing the symbolic name for the old version and keep the symbolic name for the new version, but having both bundles as full-fledged independent bundles. That way the dependencies are easier to upgrade in the pom.xml.
Dependencies are not based on symbolic name, but on maven coordinates.
Carsten
>
>> On 26. Apr 2017, at 14:47, Carsten Ziegeler <cz...@apache.org> wrote:
>>
>> Oliver Lietz wrote
>>> On Tuesday 25 April 2017 14:09:51 Carsten Ziegeler wrote:
>>>> I'm moving this into a separate thread to make the discussion easier.
>>>>
>>>> With the current state of the xss module, we would break every consumer
>>>> and require her to upgrade code (release their own modules depending on
>>>> XSS etc). As xss is pretty popular, this means a high burden on our
>>>> downstream users.
>>>>
>>>> I think we have these options:
>>>> 1) Pass on the pain to our users, simply release as 2.0.0 and require
>>>> everyone to upgrade
>>>>
>>>> 2) Release the new api as 2.0 under a different symbolic name allowing
>>>> our users to have new and old side by side. In that case we would need
>>>> to deprecate 1.x and users should upgrade over time.
>>>>
>>>> 3) Best effort: we release as 1.x and know that this is an incompatible
>>>> change. This will only break users of the old JSONUtil, everyone else
>>>> runs without any problems. Unfortunately if others are using the util,
>>>> this will only be detected at runtime.
>>>>
>>>> Are the other/better options?
>>>
>>> Can we keep the symbolic name for the new bundle and provide an additional
>>> compat bundle with old JSONUtil?
>>>
>> No, unfortunately not - the JSONUtil is part of the API package. Although it
>> might be possible through a fragment, but I'm unsure what the
>> implications are
>> (if that works at all).
>>
>> Regards
>> Carsten
>>
>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Versioning of o.a.s.xss [was move o.a.s.xss.JSONUtil into a
separate package]
Posted by Konrad Windszus <ko...@gmx.de>.
I guess Oliver Lietz meant, changing the symbolic name for the old version and keep the symbolic name for the new version, but having both bundles as full-fledged independent bundles. That way the dependencies are easier to upgrade in the pom.xml.
> On 26. Apr 2017, at 14:47, Carsten Ziegeler <cz...@apache.org> wrote:
>
> Oliver Lietz wrote
>> On Tuesday 25 April 2017 14:09:51 Carsten Ziegeler wrote:
>>> I'm moving this into a separate thread to make the discussion easier.
>>>
>>> With the current state of the xss module, we would break every consumer
>>> and require her to upgrade code (release their own modules depending on
>>> XSS etc). As xss is pretty popular, this means a high burden on our
>>> downstream users.
>>>
>>> I think we have these options:
>>> 1) Pass on the pain to our users, simply release as 2.0.0 and require
>>> everyone to upgrade
>>>
>>> 2) Release the new api as 2.0 under a different symbolic name allowing
>>> our users to have new and old side by side. In that case we would need
>>> to deprecate 1.x and users should upgrade over time.
>>>
>>> 3) Best effort: we release as 1.x and know that this is an incompatible
>>> change. This will only break users of the old JSONUtil, everyone else
>>> runs without any problems. Unfortunately if others are using the util,
>>> this will only be detected at runtime.
>>>
>>> Are the other/better options?
>>
>> Can we keep the symbolic name for the new bundle and provide an additional
>> compat bundle with old JSONUtil?
>>
> No, unfortunately not - the JSONUtil is part of the API package. Although it
> might be possible through a fragment, but I'm unsure what the
> implications are
> (if that works at all).
>
> Regards
> Carsten
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
Re: Versioning of o.a.s.xss [was move o.a.s.xss.JSONUtil into a
separate package]
Posted by Carsten Ziegeler <cz...@apache.org>.
Oliver Lietz wrote
> On Tuesday 25 April 2017 14:09:51 Carsten Ziegeler wrote:
>> I'm moving this into a separate thread to make the discussion easier.
>>
>> With the current state of the xss module, we would break every consumer
>> and require her to upgrade code (release their own modules depending on
>> XSS etc). As xss is pretty popular, this means a high burden on our
>> downstream users.
>>
>> I think we have these options:
>> 1) Pass on the pain to our users, simply release as 2.0.0 and require
>> everyone to upgrade
>>
>> 2) Release the new api as 2.0 under a different symbolic name allowing
>> our users to have new and old side by side. In that case we would need
>> to deprecate 1.x and users should upgrade over time.
>>
>> 3) Best effort: we release as 1.x and know that this is an incompatible
>> change. This will only break users of the old JSONUtil, everyone else
>> runs without any problems. Unfortunately if others are using the util,
>> this will only be detected at runtime.
>>
>> Are the other/better options?
>
> Can we keep the symbolic name for the new bundle and provide an additional
> compat bundle with old JSONUtil?
>
No, unfortunately not - the JSONUtil is part of the API package. Although it
might be possible through a fragment, but I'm unsure what the
implications are
(if that works at all).
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Versioning of o.a.s.xss [was move o.a.s.xss.JSONUtil into a separate package]
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Tuesday 25 April 2017 14:09:51 Carsten Ziegeler wrote:
> I'm moving this into a separate thread to make the discussion easier.
>
> With the current state of the xss module, we would break every consumer
> and require her to upgrade code (release their own modules depending on
> XSS etc). As xss is pretty popular, this means a high burden on our
> downstream users.
>
> I think we have these options:
> 1) Pass on the pain to our users, simply release as 2.0.0 and require
> everyone to upgrade
>
> 2) Release the new api as 2.0 under a different symbolic name allowing
> our users to have new and old side by side. In that case we would need
> to deprecate 1.x and users should upgrade over time.
>
> 3) Best effort: we release as 1.x and know that this is an incompatible
> change. This will only break users of the old JSONUtil, everyone else
> runs without any problems. Unfortunately if others are using the util,
> this will only be detected at runtime.
>
> Are the other/better options?
Can we keep the symbolic name for the new bundle and provide an additional
compat bundle with old JSONUtil?
Regards,
O.
> I think we should definitely not do 1)
>
> Carsten
Re: Versioning of o.a.s.xss [was move o.a.s.xss.JSONUtil into a
separate package]
Posted by Karl Pauls <ka...@gmail.com>.
I would argue for #2 as well.
In regard to the JSONUtil, we should definitely either move it to a
different package or delete it completely (see other thread).
regards,
Karl
On Tue, Apr 25, 2017 at 4:03 PM, Justin Edelson
<ju...@justinedelson.com> wrote:
> Good point. To be clear, what I assumed #2 included moving that JSONUtil
> class to a separate package.
>
> On Tue, Apr 25, 2017 at 10:02 AM Konrad Windszus <ko...@gmx.de> wrote:
>
>> I am also in favour of #2 but I would strongly recommend to put JSONUtil
>> to a dedicated subpackage. Even in the new version this has a dependency
>> towards javax.json which may change in the future. If we have to do another
>> change in the future in that area, this would only affect the package with
>> the JSONUtil but not e.g. XSSApi.
>> > On 25. Apr 2017, at 14:21, Justin Edelson <ju...@justinedelson.com>
>> wrote:
>> >
>> > I think #2 is the best option of these and I can't see another reasonable
>> > path forward.
>> >
>> > Regards,
>> > Justin
>> >
>> > On Tue, Apr 25, 2017 at 8:09 AM Carsten Ziegeler <cz...@apache.org>
>> > wrote:
>> >
>> >> I'm moving this into a separate thread to make the discussion easier.
>> >>
>> >> With the current state of the xss module, we would break every consumer
>> >> and require her to upgrade code (release their own modules depending on
>> >> XSS etc). As xss is pretty popular, this means a high burden on our
>> >> downstream users.
>> >>
>> >> I think we have these options:
>> >> 1) Pass on the pain to our users, simply release as 2.0.0 and require
>> >> everyone to upgrade
>> >>
>> >> 2) Release the new api as 2.0 under a different symbolic name allowing
>> >> our users to have new and old side by side. In that case we would need
>> >> to deprecate 1.x and users should upgrade over time.
>> >>
>> >> 3) Best effort: we release as 1.x and know that this is an incompatible
>> >> change. This will only break users of the old JSONUtil, everyone else
>> >> runs without any problems. Unfortunately if others are using the util,
>> >> this will only be detected at runtime.
>> >>
>> >> Are the other/better options?
>> >>
>> >> I think we should definitely not do 1)
>> >>
>> >> Carsten
>> >>
>> >> --
>> >> Carsten Ziegeler
>> >> Adobe Research Switzerland
>> >> cziegeler@apache.org
>> >>
>>
>>
--
Karl Pauls
karlpauls@gmail.com
Re: Versioning of o.a.s.xss [was move o.a.s.xss.JSONUtil into a
separate package]
Posted by Justin Edelson <ju...@justinedelson.com>.
Good point. To be clear, what I assumed #2 included moving that JSONUtil
class to a separate package.
On Tue, Apr 25, 2017 at 10:02 AM Konrad Windszus <ko...@gmx.de> wrote:
> I am also in favour of #2 but I would strongly recommend to put JSONUtil
> to a dedicated subpackage. Even in the new version this has a dependency
> towards javax.json which may change in the future. If we have to do another
> change in the future in that area, this would only affect the package with
> the JSONUtil but not e.g. XSSApi.
> > On 25. Apr 2017, at 14:21, Justin Edelson <ju...@justinedelson.com>
> wrote:
> >
> > I think #2 is the best option of these and I can't see another reasonable
> > path forward.
> >
> > Regards,
> > Justin
> >
> > On Tue, Apr 25, 2017 at 8:09 AM Carsten Ziegeler <cz...@apache.org>
> > wrote:
> >
> >> I'm moving this into a separate thread to make the discussion easier.
> >>
> >> With the current state of the xss module, we would break every consumer
> >> and require her to upgrade code (release their own modules depending on
> >> XSS etc). As xss is pretty popular, this means a high burden on our
> >> downstream users.
> >>
> >> I think we have these options:
> >> 1) Pass on the pain to our users, simply release as 2.0.0 and require
> >> everyone to upgrade
> >>
> >> 2) Release the new api as 2.0 under a different symbolic name allowing
> >> our users to have new and old side by side. In that case we would need
> >> to deprecate 1.x and users should upgrade over time.
> >>
> >> 3) Best effort: we release as 1.x and know that this is an incompatible
> >> change. This will only break users of the old JSONUtil, everyone else
> >> runs without any problems. Unfortunately if others are using the util,
> >> this will only be detected at runtime.
> >>
> >> Are the other/better options?
> >>
> >> I think we should definitely not do 1)
> >>
> >> Carsten
> >>
> >> --
> >> Carsten Ziegeler
> >> Adobe Research Switzerland
> >> cziegeler@apache.org
> >>
>
>
Re: Versioning of o.a.s.xss [was move o.a.s.xss.JSONUtil into a
separate package]
Posted by Konrad Windszus <ko...@gmx.de>.
I am also in favour of #2 but I would strongly recommend to put JSONUtil to a dedicated subpackage. Even in the new version this has a dependency towards javax.json which may change in the future. If we have to do another change in the future in that area, this would only affect the package with the JSONUtil but not e.g. XSSApi.
> On 25. Apr 2017, at 14:21, Justin Edelson <ju...@justinedelson.com> wrote:
>
> I think #2 is the best option of these and I can't see another reasonable
> path forward.
>
> Regards,
> Justin
>
> On Tue, Apr 25, 2017 at 8:09 AM Carsten Ziegeler <cz...@apache.org>
> wrote:
>
>> I'm moving this into a separate thread to make the discussion easier.
>>
>> With the current state of the xss module, we would break every consumer
>> and require her to upgrade code (release their own modules depending on
>> XSS etc). As xss is pretty popular, this means a high burden on our
>> downstream users.
>>
>> I think we have these options:
>> 1) Pass on the pain to our users, simply release as 2.0.0 and require
>> everyone to upgrade
>>
>> 2) Release the new api as 2.0 under a different symbolic name allowing
>> our users to have new and old side by side. In that case we would need
>> to deprecate 1.x and users should upgrade over time.
>>
>> 3) Best effort: we release as 1.x and know that this is an incompatible
>> change. This will only break users of the old JSONUtil, everyone else
>> runs without any problems. Unfortunately if others are using the util,
>> this will only be detected at runtime.
>>
>> Are the other/better options?
>>
>> I think we should definitely not do 1)
>>
>> Carsten
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>>
Re: Versioning of o.a.s.xss [was move o.a.s.xss.JSONUtil into a
separate package]
Posted by Justin Edelson <ju...@justinedelson.com>.
I think #2 is the best option of these and I can't see another reasonable
path forward.
Regards,
Justin
On Tue, Apr 25, 2017 at 8:09 AM Carsten Ziegeler <cz...@apache.org>
wrote:
> I'm moving this into a separate thread to make the discussion easier.
>
> With the current state of the xss module, we would break every consumer
> and require her to upgrade code (release their own modules depending on
> XSS etc). As xss is pretty popular, this means a high burden on our
> downstream users.
>
> I think we have these options:
> 1) Pass on the pain to our users, simply release as 2.0.0 and require
> everyone to upgrade
>
> 2) Release the new api as 2.0 under a different symbolic name allowing
> our users to have new and old side by side. In that case we would need
> to deprecate 1.x and users should upgrade over time.
>
> 3) Best effort: we release as 1.x and know that this is an incompatible
> change. This will only break users of the old JSONUtil, everyone else
> runs without any problems. Unfortunately if others are using the util,
> this will only be detected at runtime.
>
> Are the other/better options?
>
> I think we should definitely not do 1)
>
> Carsten
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
Re: Versioning of o.a.s.xss [was move o.a.s.xss.JSONUtil into a
separate package]
Posted by Carsten Ziegeler <cz...@apache.org>.
Carsten Ziegeler wrote
> It seems option 2 is our favorite here:
>> 2) Release the new api as 2.0 under a different symbolic name allowing
>> our users to have new and old side by side. In that case we would need
>> to deprecate 1.x and users should upgrade over time.
>>
>
> Now, I personally still think we should not add a new JSONUtil as it's
> usage is questionable.
>
> Second comment, if we increase the version to 2.0, are we happy with the
> current API or is there something we could improve/change there?
> Users have to adjust their code anyway (or at least recompile/rebuild),
> so if there is anything we should improve, now is a good time. (I'm not
> implying there is, just bringing up the opportunity)
>
Just had a look at the API and I think we should remove these methods
from XSSAPI:
XSSAPI getRequestSpecificAPI(SlingHttpServletRequest request);
XSSAPI getResourceResolverSpecificAPI(ResourceResolver
resourceResolver);
Neither the request nor the resource resolver are used, the
implementation just returns "this". And by removing these methods we
remove a unnecessary dependency to the Sling API
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Versioning of o.a.s.xss [was move o.a.s.xss.JSONUtil into a
separate package]
Posted by Carsten Ziegeler <cz...@apache.org>.
It seems option 2 is our favorite here:
> 2) Release the new api as 2.0 under a different symbolic name allowing
> our users to have new and old side by side. In that case we would need
> to deprecate 1.x and users should upgrade over time.
>
Now, I personally still think we should not add a new JSONUtil as it's
usage is questionable.
Second comment, if we increase the version to 2.0, are we happy with the
current API or is there something we could improve/change there?
Users have to adjust their code anyway (or at least recompile/rebuild),
so if there is anything we should improve, now is a good time. (I'm not
implying there is, just bringing up the opportunity)
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Versioning of o.a.s.xss [was move o.a.s.xss.JSONUtil into a separate
package]
Posted by Carsten Ziegeler <cz...@apache.org>.
I'm moving this into a separate thread to make the discussion easier.
With the current state of the xss module, we would break every consumer
and require her to upgrade code (release their own modules depending on
XSS etc). As xss is pretty popular, this means a high burden on our
downstream users.
I think we have these options:
1) Pass on the pain to our users, simply release as 2.0.0 and require
everyone to upgrade
2) Release the new api as 2.0 under a different symbolic name allowing
our users to have new and old side by side. In that case we would need
to deprecate 1.x and users should upgrade over time.
3) Best effort: we release as 1.x and know that this is an incompatible
change. This will only break users of the old JSONUtil, everyone else
runs without any problems. Unfortunately if others are using the util,
this will only be detected at runtime.
Are the other/better options?
I think we should definitely not do 1)
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: move o.a.s.xss.JSONUtil into a separate package
Posted by Karl Pauls <ka...@gmail.com>.
On Tue, Apr 25, 2017 at 1:53 PM, Stefan Seifert <ss...@pro-vision.de> wrote:
>
>>Do we need this util class in the api at all? (I have no idea, but just
>>asking the obvious question)
>
> perhaps not, but a lot of existing code outside there may use it. and providing an alternative on javax.json is perhaps easier to migrate to than completely removing it.
>
>
>>I understand that for semantic versioning we have to increase the major
>>version of the api. How do we deal with all the code out there currently
>>importing 1.x? Can we find a way that does not require everyone to
>>change her code?
>
> if other classes except JSONUtil are used it's a drop-in replacement, just a recompile against the latest package version is needed (or a relaxed import statement for both major versions). but this still is of course a complex tasks if a lot of bundles depend on the old major version.
>
> we might change the symbolic name of the new xss bundle to allow parallel deployment of old and new implementation.
Well, technically, that isn't needed from an OSGi perspective but it
might make things easier for Sling users given how things currently
work wrt. the installer etc.
regards,
Karl
> stefan
>
--
Karl Pauls
karlpauls@gmail.com
RE: move o.a.s.xss.JSONUtil into a separate package
Posted by Stefan Seifert <ss...@pro-vision.de>.
>Do we need this util class in the api at all? (I have no idea, but just
>asking the obvious question)
perhaps not, but a lot of existing code outside there may use it. and providing an alternative on javax.json is perhaps easier to migrate to than completely removing it.
>I understand that for semantic versioning we have to increase the major
>version of the api. How do we deal with all the code out there currently
>importing 1.x? Can we find a way that does not require everyone to
>change her code?
if other classes except JSONUtil are used it's a drop-in replacement, just a recompile against the latest package version is needed (or a relaxed import statement for both major versions). but this still is of course a complex tasks if a lot of bundles depend on the old major version.
we might change the symbolic name of the new xss bundle to allow parallel deployment of old and new implementation.
stefan
Re: move o.a.s.xss.JSONUtil into a separate package
Posted by Karl Pauls <ka...@gmail.com>.
>>> Do we need this util class in the api at all? (I have no idea, but just
>>> asking the obvious question)
>>
>> I was thinking about that too: why not just drop it completely.
>
> I think we should remove it - see my reply to Stefan.
+1
regards,
Karl
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
--
Karl Pauls
karlpauls@gmail.com
RE: move o.a.s.xss.JSONUtil into a separate package
Posted by Stefan Seifert <ss...@pro-vision.de>.
>> I was thinking about that too: why not just drop it completely.
>
>I think we should remove it - see my reply to Stefan.
+1 from my side - we can always add it later.
stefan
Re: move o.a.s.xss.JSONUtil into a separate package
Posted by Carsten Ziegeler <cz...@apache.org>.
Karl Pauls wrote
> On Tue, Apr 25, 2017 at 1:34 PM, Carsten Ziegeler <cz...@apache.org> wrote:
>> Karl Pauls wrote
>>> Hi,
>>>
>>> as discussed with Stefan Seifert on SLING-6685, we would like to move
>>> the JSONUtil class out of the o.a.s.xss package into a separate sub
>>> package (o.a.s.xss.json).
>>>
>>> Right now, it introduces a dependency on the javax.json package for
>>> the o.a.s.xss package. That is the reason we have to bump the version
>>> to 2.0.0 due to the commons.json removable. If we move it into its own
>>> package we wouldn't have to do that if we every switch json providers
>>> again :-).
>>>
>>> As we are bumping the major version anyways, I don't think this is a
>>> big deal - hence, I'm calling for lazy consensus (in other words, if
>>> you object, speak up now).
>>>
>> Do we need this util class in the api at all? (I have no idea, but just
>> asking the obvious question)
>
> I was thinking about that too: why not just drop it completely.
I think we should remove it - see my reply to Stefan.
Regards
Carsten
>
> I would actually be in favour of that but at the same time, we already
> kind of pull the rug out from under commons.json users (no deprecation
> etc.)
> so I figured it might be nicer to first move it to a separate package
> with the update to javax.json and maybe deprecate
> it there and drop the package in the future...
>
>> If yes, moving it to a separate package and maybe naming either the
>> package or the class in a way that it is clear that this is bound to
>> javax.json and not a general purpose json util sounds like the right
>> thing to do.
>
> I'm well known for being terrible in naming things - hence, if you
> have a good name that sounds like a good idea. Otherwise, I'll stick
> with xss.json :-)
>
>> I understand that for semantic versioning we have to increase the major
>> version of the api. How do we deal with all the code out there currently
>> importing 1.x? Can we find a way that does not require everyone to
>> change her code?
>
> Well, that be hard as we don't know if they actually use the JSONUtil
> class or not (thats why I want to at a minimum move the JSONUtil out
> of the xss package so that this doesn't happen again). However, if you
> have a good idea I'm all ears.
>
> regards,
>
> Karl
>
>> Regards
>>
>> Carsten
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>
>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: move o.a.s.xss.JSONUtil into a separate package
Posted by Karl Pauls <ka...@gmail.com>.
On Tue, Apr 25, 2017 at 1:34 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> Karl Pauls wrote
>> Hi,
>>
>> as discussed with Stefan Seifert on SLING-6685, we would like to move
>> the JSONUtil class out of the o.a.s.xss package into a separate sub
>> package (o.a.s.xss.json).
>>
>> Right now, it introduces a dependency on the javax.json package for
>> the o.a.s.xss package. That is the reason we have to bump the version
>> to 2.0.0 due to the commons.json removable. If we move it into its own
>> package we wouldn't have to do that if we every switch json providers
>> again :-).
>>
>> As we are bumping the major version anyways, I don't think this is a
>> big deal - hence, I'm calling for lazy consensus (in other words, if
>> you object, speak up now).
>>
> Do we need this util class in the api at all? (I have no idea, but just
> asking the obvious question)
I was thinking about that too: why not just drop it completely.
I would actually be in favour of that but at the same time, we already
kind of pull the rug out from under commons.json users (no deprecation
etc.)
so I figured it might be nicer to first move it to a separate package
with the update to javax.json and maybe deprecate
it there and drop the package in the future...
> If yes, moving it to a separate package and maybe naming either the
> package or the class in a way that it is clear that this is bound to
> javax.json and not a general purpose json util sounds like the right
> thing to do.
I'm well known for being terrible in naming things - hence, if you
have a good name that sounds like a good idea. Otherwise, I'll stick
with xss.json :-)
> I understand that for semantic versioning we have to increase the major
> version of the api. How do we deal with all the code out there currently
> importing 1.x? Can we find a way that does not require everyone to
> change her code?
Well, that be hard as we don't know if they actually use the JSONUtil
class or not (thats why I want to at a minimum move the JSONUtil out
of the xss package so that this doesn't happen again). However, if you
have a good idea I'm all ears.
regards,
Karl
> Regards
>
> Carsten
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
--
Karl Pauls
karlpauls@gmail.com
Re: move o.a.s.xss.JSONUtil into a separate package
Posted by Carsten Ziegeler <cz...@apache.org>.
Karl Pauls wrote
> Hi,
>
> as discussed with Stefan Seifert on SLING-6685, we would like to move
> the JSONUtil class out of the o.a.s.xss package into a separate sub
> package (o.a.s.xss.json).
>
> Right now, it introduces a dependency on the javax.json package for
> the o.a.s.xss package. That is the reason we have to bump the version
> to 2.0.0 due to the commons.json removable. If we move it into its own
> package we wouldn't have to do that if we every switch json providers
> again :-).
>
> As we are bumping the major version anyways, I don't think this is a
> big deal - hence, I'm calling for lazy consensus (in other words, if
> you object, speak up now).
>
Do we need this util class in the api at all? (I have no idea, but just
asking the obvious question)
If yes, moving it to a separate package and maybe naming either the
package or the class in a way that it is clear that this is bound to
javax.json and not a general purpose json util sounds like the right
thing to do.
I understand that for semantic versioning we have to increase the major
version of the api. How do we deal with all the code out there currently
importing 1.x? Can we find a way that does not require everyone to
change her code?
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org