Removing commons.json guidance

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Removing commons.json guidance

Nicolas Peltier-3
Hey Karl,

I see you created a few JIRAs on removing commons.json I followed the effort about from rather far away.
Would it be possible to indicate some wiki or doc on what are the guidelines following that change?

Nicolas
Reply | Threaded
Open this post in threaded view
|

Re: Removing commons.json guidance

Karl Pauls
Hi Nicolas,

I'm not sure I 100% understand what you are asking but in a nutshell,
the org.json license has been moved to CAT-X (i.e., not compatible
with AL). Subsequently, we can not release anything that contains
org.json or derived code. In our case, this mostly means we can't use
o.a.s.commons.json anymore.

We did look into alternatives and settled with using the
o.a.felix.util.json.JSONWriter embedded where a bundle is only writing
out simple json and javax.json otherwise. Towards that end, we created
a new o.a.s.commons.johnzon bundle that provides javax.json.

I did a first push recently and reworked all bundles that are
currently in the launchpad. Consequently, the launchpad currently
doesn't require org.json nor o.a.s.commons.json anymore. However, we
have still quite some other bundles and places like integration tests
etc. that need to be reworked.

For that, I just created SLING-6887 as the umbrella issue. Unless I
missed something, if all subtask on that issue are done (i.e., for
each subtask we reworked the associated bundle to not include or
depend on org.json, o.a.s.commons.json, nor
o.a.jackrabbit.commons.json and use javax.json or the Felix JSONWriter
instead, respectively) we hopefully have a completely org.json and
derived code free trunk.

Since I "volunteered" in the first place, I'm still commited to work
on this removal and I will try to pick up the sub-task of SLING-6887
one by one but certainly contributions are welcome :-).

Overall, the policy is: no more org.json/commons.json. The guideline
is, try to use javax.json if its complicated, otherwise, see if the
Felix JSONWriter is enough and if so, us that one but embed it
directly into the bundle.

Does this help?

regards,

Karl

On Mon, May 29, 2017 at 1:15 PM, Nicolas Peltier
<[hidden email]> wrote:
> Hey Karl,
>
> I see you created a few JIRAs on removing commons.json I followed the effort about from rather far away.
> Would it be possible to indicate some wiki or doc on what are the guidelines following that change?
>
> Nicolas



--
Karl Pauls
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Removing commons.json guidance

Nicolas Peltier-3
Hi Karl,

Thanks for this! (Thought I needed to do the work :-) )

Nicolas

> On 29 May 2017, at 15:34, Karl Pauls <[hidden email]> wrote:
>
> Hi Nicolas,
>
> I'm not sure I 100% understand what you are asking but in a nutshell,
> the org.json license has been moved to CAT-X (i.e., not compatible
> with AL). Subsequently, we can not release anything that contains
> org.json or derived code. In our case, this mostly means we can't use
> o.a.s.commons.json anymore.
>
> We did look into alternatives and settled with using the
> o.a.felix.util.json.JSONWriter embedded where a bundle is only writing
> out simple json and javax.json otherwise. Towards that end, we created
> a new o.a.s.commons.johnzon bundle that provides javax.json.
>
> I did a first push recently and reworked all bundles that are
> currently in the launchpad. Consequently, the launchpad currently
> doesn't require org.json nor o.a.s.commons.json anymore. However, we
> have still quite some other bundles and places like integration tests
> etc. that need to be reworked.
>
> For that, I just created SLING-6887 as the umbrella issue. Unless I
> missed something, if all subtask on that issue are done (i.e., for
> each subtask we reworked the associated bundle to not include or
> depend on org.json, o.a.s.commons.json, nor
> o.a.jackrabbit.commons.json and use javax.json or the Felix JSONWriter
> instead, respectively) we hopefully have a completely org.json and
> derived code free trunk.
>
> Since I "volunteered" in the first place, I'm still commited to work
> on this removal and I will try to pick up the sub-task of SLING-6887
> one by one but certainly contributions are welcome :-).
>
> Overall, the policy is: no more org.json/commons.json. The guideline
> is, try to use javax.json if its complicated, otherwise, see if the
> Felix JSONWriter is enough and if so, us that one but embed it
> directly into the bundle.
>
> Does this help?
>
> regards,
>
> Karl
>
> On Mon, May 29, 2017 at 1:15 PM, Nicolas Peltier
> <[hidden email]> wrote:
>> Hey Karl,
>>
>> I see you created a few JIRAs on removing commons.json I followed the effort about from rather far away.
>> Would it be possible to indicate some wiki or doc on what are the guidelines following that change?
>>
>> Nicolas
>
>
>
> --
> Karl Pauls
> [hidden email]