geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Owen Nichols <onich...@pivotal.io>
Subject Re: [PROPOSAL] adding java-jq to GEODE dependency for testing
Date Wed, 25 Sep 2019 19:55:04 GMT
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 <jiliao@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 <onichols@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 <dsmith@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 <abaker@pivotal.io> wrote:
>>> 
>>>> Sounds good, thanks for the heads up.
>>>> 
>>>> Anthony
>>>> 
>>>> 
>>>>> On Sep 25, 2019, at 8:37 AM, Jinmei Liao <jiliao@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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message