On Tue, Apr 25, 2017 at 1:34 PM, Carsten Ziegeler <cziege...@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 > cziege...@apache.org -- Karl Pauls karlpa...@gmail.com