Re: Removing dependency to org.json
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:cziege...@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-a1f8b0718...@apache.org%3E >>> [2] >> https://lists.apache.org/thread.html/ee90e16264776d160fdf04077a63f8eaf0681d >> bbb8bc1eae26764437@%3Cdev.sling.apache.org%3E >>> >> >> >> >> >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> cziege...@apache.org > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
RE: Removing dependency to org.json
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:cziege...@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-a1f8b0718...@apache.org%3E >> [2] >https://lists.apache.org/thread.html/ee90e16264776d160fdf04077a63f8eaf0681d >bbb8bc1eae26764437@%3Cdev.sling.apache.org%3E >> > > > > >-- >Carsten Ziegeler >Adobe Research Switzerland >cziege...@apache.org
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-a1f8b0718...@apache.org%3E > [2] > https://lists.apache.org/thread.html/ee90e16264776d160fdf04077a63f8eaf0681dbbb8bc1eae26764437@%3Cdev.sling.apache.org%3E > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
RE: Removing dependency to org.json
>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-a1f8b0718...@apache.org%3E [2] https://lists.apache.org/thread.html/ee90e16264776d160fdf04077a63f8eaf0681dbbb8bc1eae26764437@%3Cdev.sling.apache.org%3E
Re: Removing dependency to org.json
Thanks Carsten for the example commit. I have changed Log WebConsole Plugin. However when doing the same for slf4j-mdc I hit FELIX-. Would see if I can workaround that for now Chetan Mehrotra On Mon, Feb 20, 2017 at 1:56 PM, Carsten Ziegeler 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 > cziege...@apache.org
Re: Removing dependency to org.json
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 cziege...@apache.org
Re: Removing dependency to org.json
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 cziege...@apache.org
Re: Removing dependency to org.json
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 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-a1f8b0718...@apache.org%3E > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
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-a1f8b0718...@apache.org%3E -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org