I would prefer we stick to one family of libraries for JSON. So, if there's a comparable release from Jackson, then I think we should go with that instead.
On Wed, Sep 25, 2019 at 12:55 PM Owen Nichols <onich...@pivotal.io> wrote: > The Jackson-jq project actually imports the full testsuite from the “real" > jq project, and asks that any discrepancy be reported as a bug. They list > the known differences in great detail…so unless you are using $__loc__ < > https://stedolan.github.io/jq/manual/v1.5/#$__loc__> or date arithmetic > or file I/O in your jq queries, everything else is there. > > Since the goal of using jq in tests is really to validate against the > “real” jq that customers would be using, that might be a good argument for > using the native wrapper approach. On the other hand, since Geode's usage > is entirely in tests, switching to another implementation should be easy to > validate, just run the tests. And since the set of JQ inputs is fully > under our control, it wouldn’t be hard to work within the constraints of > the pure-java implementation. > > I don’t have a strong opinion on pure-java, just brought this up since Dan > mentioned the concern with introducing native libs. I don’t know if any > Geode developers are running the tests on platforms other than the 3 > supported by arakelian (Mac/Windows/Linux). > > > > On Sep 25, 2019, at 10:41 AM, Jinmei Liao <jil...@pivotal.io> wrote: > > > > I did look at jackson-jq before I considered java-jq, but it is a > > re-implementation of jq and this statement on that site puts me off: > > "jackson-jq > > aims to be a compatible jq implementation. However, not all the features > > are available; some features are not relevant as being a java library and > > some features are just yet to be implemented." > > > > On Wed, Sep 25, 2019 at 9:57 AM Owen Nichols <onich...@pivotal.io> > wrote: > > > >> For a pure-java implementation, might be worth considering > >> https://github.com/eiiches/jackson-jq > >> > >>> On Sep 25, 2019, at 9:40 AM, Dan Smith <dsm...@pivotal.io> wrote: > >>> > >>> +1 - sounds good. > >>> > >>> BTW - We've previously found libraries that use JNA tend to be more > >>> flaky/platform dependent than pure java libaries - for example we > ripped > >>> out a snappy native wrapper in favor of a pure java implementation. > >>> > >>> -Dan > >>> > >>> On Wed, Sep 25, 2019 at 8:39 AM Anthony Baker <aba...@pivotal.io> > wrote: > >>> > >>>> Sounds good, thanks for the heads up. > >>>> > >>>> Anthony > >>>> > >>>> > >>>>> On Sep 25, 2019, at 8:37 AM, Jinmei Liao <jil...@pivotal.io> wrote: > >>>>> > >>>>> Management rest api wants to add some default jq selector to the > >> swagger > >>>>> api docs so that the downstream client tool can use it as a starting > >>>> point > >>>>> to filter/format the json response to a more readable form. In order > to > >>>>> test these jq selectors, we would like to use a java library > described > >>>>> here: https://github.com/arakelian/java-jq, it basically provides a > >> java > >>>>> wrapper around 'jq' tool. Github shows both MIT and apache license. > We > >>>> will > >>>>> only be using it for testing. > >>>>> > >>>>> -- > >>>>> Cheers > >>>>> > >>>>> Jinmei > >>>> > >>>> > >> > >> > > > > -- > > Cheers > > > > Jinmei > >
