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 2017/02/11 12:55:57 UTC
Removing dependency to org.json
Hi,
as Jim has explained in [1] we have to remove the usage of the json.org
library from our code base as the licence is not in the excepted
category anymore. This does not affect released code.
The biggest usage is our own commons.json library which is currently a
copy of the org.json source. So we have to completely replace this.
Below are the other files currently using org.json. The list is not to
long and shouldn't pose problems replacing them I hope.
It would be great if people could volunteer for migrating/changing the code.
bundles/commons/log-webconsole/src/test/java/org/apache/sling/commons/log/webconsole/LogTestBase.java
bundles/commons/metrics/src/main/java/org/apache/sling/commons/metrics/internal/JSONReporter.java
bundles/commons/metrics/src/test/java/org/apache/sling/commons/metrics/internal/JSONReporterTest.java
contrib/extensions/slf4j-mdc/src/test/java/org/apache/sling/extensions/mdc/integration/ITMDCFilter.java
contrib/extensions/slf4j-mdc/src/test/java/org/apache/sling/extensions/mdc/integration/ServerConfiguration.java
contrib/extensions/slf4j-mdc/src/test/java/org/apache/sling/extensions/mdc/integration/servlet/MDCStateServlet.java
launchpad/builder/src/test/java/org/apache/sling/launchpad/SmokeIT.java
tooling/ide/api/src/org/apache/sling/ide/osgi/impl/HttpOsgiClient.java
tooling/ide/eclipse-test/src/org/apache/sling/ide/test/impl/helpers/ExternalSlingLaunchpad.java
tooling/ide/impl-resource/src/org/apache/sling/ide/impl/resource/transport/GetNodeContentCommand.java
tooling/ide/impl-resource/src/org/apache/sling/ide/impl/resource/transport/ListChildrenCommand.java
Regards
Carsten
[1]
https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201611.mbox/%3C0CE2E8C9-D9B7-404D-93EF-A1F8B07189BF@apache.org%3E
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Removing dependency to org.json
Posted by Carsten Ziegeler <cz...@apache.org>.
Chetan Mehrotra wrote
> Hi Carsten,
>
> I can take care of log,metrics,slf4j-mdc
>
> Whats the recommended approach to replace the current usage?
I think it would be good to replace it with something simple, which does
not add new dependencies.
In the Felix project, we added a simple writer and parser for json to
the utils project. These are single classes that can easily be embedded.
So we could use the same classes at least for some places.
Version 1.9.0 of utils is currently under vote and should be out today
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Removing dependency to org.json
Posted by Chetan Mehrotra <ch...@gmail.com>.
Thanks Carsten for the example commit. I have changed Log WebConsole
Plugin. However when doing the same for slf4j-mdc I hit FELIX-5555.
Would see if I can workaround that for now
Chetan Mehrotra
On Mon, Feb 20, 2017 at 1:56 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> Chetan Mehrotra wrote
>> Hi Carsten,
>>
>> I can take care of log,metrics,slf4j-mdc
>>
>> Whats the recommended approach to replace the current usage?
>
> As an exampled I've replaced the usage in the metrics project.
>
> I've also removed the usage from launchpad.
>
> Regards
> Carsten
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
Re: Removing dependency to org.json
Posted by Carsten Ziegeler <cz...@apache.org>.
Chetan Mehrotra wrote
> Hi Carsten,
>
> I can take care of log,metrics,slf4j-mdc
>
> Whats the recommended approach to replace the current usage?
As an exampled I've replaced the usage in the metrics project.
I've also removed the usage from launchpad.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Removing dependency to org.json
Posted by Chetan Mehrotra <ch...@gmail.com>.
Hi Carsten,
I can take care of log,metrics,slf4j-mdc
Whats the recommended approach to replace the current usage?
Chetan Mehrotra
On Sat, Feb 11, 2017 at 6:25 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> Hi,
>
> as Jim has explained in [1] we have to remove the usage of the json.org
> library from our code base as the licence is not in the excepted
> category anymore. This does not affect released code.
>
> The biggest usage is our own commons.json library which is currently a
> copy of the org.json source. So we have to completely replace this.
>
> Below are the other files currently using org.json. The list is not to
> long and shouldn't pose problems replacing them I hope.
>
> It would be great if people could volunteer for migrating/changing the code.
>
> bundles/commons/log-webconsole/src/test/java/org/apache/sling/commons/log/webconsole/LogTestBase.java
>
> bundles/commons/metrics/src/main/java/org/apache/sling/commons/metrics/internal/JSONReporter.java
> bundles/commons/metrics/src/test/java/org/apache/sling/commons/metrics/internal/JSONReporterTest.java
>
> contrib/extensions/slf4j-mdc/src/test/java/org/apache/sling/extensions/mdc/integration/ITMDCFilter.java
> contrib/extensions/slf4j-mdc/src/test/java/org/apache/sling/extensions/mdc/integration/ServerConfiguration.java
> contrib/extensions/slf4j-mdc/src/test/java/org/apache/sling/extensions/mdc/integration/servlet/MDCStateServlet.java
>
> launchpad/builder/src/test/java/org/apache/sling/launchpad/SmokeIT.java
>
> tooling/ide/api/src/org/apache/sling/ide/osgi/impl/HttpOsgiClient.java
> tooling/ide/eclipse-test/src/org/apache/sling/ide/test/impl/helpers/ExternalSlingLaunchpad.java
> tooling/ide/impl-resource/src/org/apache/sling/ide/impl/resource/transport/GetNodeContentCommand.java
> tooling/ide/impl-resource/src/org/apache/sling/ide/impl/resource/transport/ListChildrenCommand.java
>
> Regards
> Carsten
>
> [1]
> https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201611.mbox/%3C0CE2E8C9-D9B7-404D-93EF-A1F8B07189BF@apache.org%3E
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
Re: Removing dependency to org.json
Posted by Carsten Ziegeler <cz...@apache.org>.
Stefan Seifert wrote
> i've created https://issues.apache.org/jira/browse/SLING-6536 to track option a)
> unfortunately the unit test converage to the affected classes is not very high, this makes replacing the impl difficult.
>
True, I think someone posted a link on the felix dev list some time ago
about a clean room implementation from google/android of the json.org
api. That one has ASF license, so maybe we can just copy that code, add
ordering and are done
Carsten
> stefan
>
>> -----Original Message-----
>> From: Carsten Ziegeler [mailto:cziegeler@apache.org]
>> Sent: Tuesday, February 21, 2017 9:21 AM
>> To: dev@sling.apache.org
>> Subject: Re: Removing dependency to org.json
>>
>> Stefan Seifert wrote
>>>
>>>> The biggest usage is our own commons.json library which is currently a
>>>> copy of the org.json source. So we have to completely replace this.
>>>
>>> do we have a plan what to do about commons.json?
>>
>> No :) So let's create one.
>>
>>> do we plan to keep the existing exported API and just replace the
>> implementation?
>>
>> I think we have to options:
>> a) keep the API and replace the impl
>> b) completely get rid of the module and remove it's usage everywhere.
>>
>> I think, even if we go with a) we should deprecate the API and replace
>> it's usage over time.
>> On the other hand, if we just do b) then everyone still using
>> commons.json suffers from the problematic license. Not sure how much of
>> a problem that is though.
>>
>>> do we have a list of features in what ways this implementation differs
>>from json.org, or from others which may replace it (see discussion on [2])?
>>
>> I guess we don't. I think we added ordering, but other than that I'm not
>> aware of functional changes.
>>
>>>
>>> after playing around with the new simple JSONParser from felix utils
>> there are at least two major differences which are also deviations from the
>> JSON spec:
>>> - the parser keeps object ordering (like gson, jackson, but not following
>> the spec)
>>> - the parser can parse files which includes comments and ignores them
>> (comments not allowed in spec)
>>>
>>> if i read jim's post [1] correct we have to find a solution within the
>> next two months, after this we can not make new releases of commons.json or
>> any library that depends on it. this affects ~45 sling modules.
>>
>> Wow, so we're using this library a lot. I guess we should go with a) in
>> this case.
>>
>> Carsten
>>
>>>
>>> stefan
>>>
>>> [1] https://mail-archives.apache.org/mod_mbox/www-legal-
>> discuss/201611.mbox/%3C0CE2E8C9-D9B7-404D-93EF-A1F8B07189BF@apache.org%3E
>>> [2]
>> https://lists.apache.org/thread.html/ee90e16264776d160fdf04077a63f8eaf0681d
>> bbb8bc1eae26764437@%3Cdev.sling.apache.org%3E
>>>
>>
>>
>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
RE: Removing dependency to org.json
Posted by Stefan Seifert <ss...@pro-vision.de>.
i've created https://issues.apache.org/jira/browse/SLING-6536 to track option a)
unfortunately the unit test converage to the affected classes is not very high, this makes replacing the impl difficult.
stefan
>-----Original Message-----
>From: Carsten Ziegeler [mailto:cziegeler@apache.org]
>Sent: Tuesday, February 21, 2017 9:21 AM
>To: dev@sling.apache.org
>Subject: Re: Removing dependency to org.json
>
>Stefan Seifert wrote
>>
>>> The biggest usage is our own commons.json library which is currently a
>>> copy of the org.json source. So we have to completely replace this.
>>
>> do we have a plan what to do about commons.json?
>
>No :) So let's create one.
>
>> do we plan to keep the existing exported API and just replace the
>implementation?
>
>I think we have to options:
>a) keep the API and replace the impl
>b) completely get rid of the module and remove it's usage everywhere.
>
>I think, even if we go with a) we should deprecate the API and replace
>it's usage over time.
>On the other hand, if we just do b) then everyone still using
>commons.json suffers from the problematic license. Not sure how much of
>a problem that is though.
>
>> do we have a list of features in what ways this implementation differs
>from json.org, or from others which may replace it (see discussion on [2])?
>
>I guess we don't. I think we added ordering, but other than that I'm not
>aware of functional changes.
>
>>
>> after playing around with the new simple JSONParser from felix utils
>there are at least two major differences which are also deviations from the
>JSON spec:
>> - the parser keeps object ordering (like gson, jackson, but not following
>the spec)
>> - the parser can parse files which includes comments and ignores them
>(comments not allowed in spec)
>>
>> if i read jim's post [1] correct we have to find a solution within the
>next two months, after this we can not make new releases of commons.json or
>any library that depends on it. this affects ~45 sling modules.
>
>Wow, so we're using this library a lot. I guess we should go with a) in
>this case.
>
>Carsten
>
>>
>> stefan
>>
>> [1] https://mail-archives.apache.org/mod_mbox/www-legal-
>discuss/201611.mbox/%3C0CE2E8C9-D9B7-404D-93EF-A1F8B07189BF@apache.org%3E
>> [2]
>https://lists.apache.org/thread.html/ee90e16264776d160fdf04077a63f8eaf0681d
>bbb8bc1eae26764437@%3Cdev.sling.apache.org%3E
>>
>
>
>
>
>--
>Carsten Ziegeler
>Adobe Research Switzerland
>cziegeler@apache.org
Re: Removing dependency to org.json
Posted by Carsten Ziegeler <cz...@apache.org>.
Stefan Seifert wrote
>
>> The biggest usage is our own commons.json library which is currently a
>> copy of the org.json source. So we have to completely replace this.
>
> do we have a plan what to do about commons.json?
No :) So let's create one.
> do we plan to keep the existing exported API and just replace the implementation?
I think we have to options:
a) keep the API and replace the impl
b) completely get rid of the module and remove it's usage everywhere.
I think, even if we go with a) we should deprecate the API and replace
it's usage over time.
On the other hand, if we just do b) then everyone still using
commons.json suffers from the problematic license. Not sure how much of
a problem that is though.
> do we have a list of features in what ways this implementation differs from json.org, or from others which may replace it (see discussion on [2])?
I guess we don't. I think we added ordering, but other than that I'm not
aware of functional changes.
>
> after playing around with the new simple JSONParser from felix utils there are at least two major differences which are also deviations from the JSON spec:
> - the parser keeps object ordering (like gson, jackson, but not following the spec)
> - the parser can parse files which includes comments and ignores them (comments not allowed in spec)
>
> if i read jim's post [1] correct we have to find a solution within the next two months, after this we can not make new releases of commons.json or any library that depends on it. this affects ~45 sling modules.
Wow, so we're using this library a lot. I guess we should go with a) in
this case.
Carsten
>
> stefan
>
> [1] https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201611.mbox/%3C0CE2E8C9-D9B7-404D-93EF-A1F8B07189BF@apache.org%3E
> [2] https://lists.apache.org/thread.html/ee90e16264776d160fdf04077a63f8eaf0681dbbb8bc1eae26764437@%3Cdev.sling.apache.org%3E
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
RE: Removing dependency to org.json
Posted by Stefan Seifert <ss...@pro-vision.de>.
>The biggest usage is our own commons.json library which is currently a
>copy of the org.json source. So we have to completely replace this.
do we have a plan what to do about commons.json?
do we plan to keep the existing exported API and just replace the implementation?
do we have a list of features in what ways this implementation differs from json.org, or from others which may replace it (see discussion on [2])?
after playing around with the new simple JSONParser from felix utils there are at least two major differences which are also deviations from the JSON spec:
- the parser keeps object ordering (like gson, jackson, but not following the spec)
- the parser can parse files which includes comments and ignores them (comments not allowed in spec)
if i read jim's post [1] correct we have to find a solution within the next two months, after this we can not make new releases of commons.json or any library that depends on it. this affects ~45 sling modules.
stefan
[1] https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201611.mbox/%3C0CE2E8C9-D9B7-404D-93EF-A1F8B07189BF@apache.org%3E
[2] https://lists.apache.org/thread.html/ee90e16264776d160fdf04077a63f8eaf0681dbbb8bc1eae26764437@%3Cdev.sling.apache.org%3E