Geode unit tests completed in 'develop/UITests' with non-zero exit code
Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/UITests/builds/288
Geode unit tests completed in 'develop/FlakyTest' with non-zero exit code
Pipeline results can be found at: Concourse: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/488
Errored: apache/geode-examples#219 (rel/v1.6.0 - 45d174a)
Build Update for apache/geode-examples - Build: #219 Status: Errored Duration: 1 min and 30 secs Commit: 45d174a (rel/v1.6.0) Author: Mike Stolz Message: Adding Mikes keys and changing version to 1.6.0 View the changeset: https://github.com/apache/geode-examples/compare/rel/v1.6.0 View the full build log and details: https://travis-ci.org/apache/geode-examples/builds/374048832?utm_source=email&utm_medium=notification -- You can configure recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications This email was sent to dev@geode.apache.org (mailto:dev@geode.apache.org) unsubscribe from this list (http://clicks.travis-ci.com/track/unsub.php?u=14313403&id=4b8d5b0d195f4f0697d2cac6f3286b7d.J7HZbFy6S8dTlH7tD%2B7uJ8FM8HM%3D&r=https%3A%2F%2Fmandrillapp.com%2Funsub%3Fmd_email%3Ddev%2540geode.apache.org)
Re: Better support for JSON gfsh results
I was under the impression that gfsh console output was intended as a more "active" interface with an operator. To that end, improved usability and a more consistent output sounds like a boon to me. On Tue, May 1, 2018 at 3:41 PM, Jens Deppe wrote: > Hi All, > > I'm working on removing our dependency on geode-json (org.json) in favor of > Jackson. Initially this work has revolved around refactoring the internal > results from gfsh commands (nothing that is user-visible). > > I'm now looking at the various gfsh 'data' commands (get, put, query and > locate) and would very much like them to produce more meaningful, (actual > JSON), structured results. > > For example, a get on a region containing a simple 'User' object produces > this output. > > Result : true > Key Class : java.lang.String > Key : jondoe > Value Class : > org.apache.geode.management.internal.cli.commands. > GetCommandIntegrationTest.User > > This is not very helpful and only really shows that the value, for the > given key, actually exists. > > Querying a PDX object is more informative: > > Result : true > Key Class : java.lang.String > Key : jondoe > Value Class : org.apache.geode.pdx.internal.PdxInstanceImpl > > username | hashcode > | > jondoe | 38de41a9 > > This brings me to the actual question. Although our Java API is backwards > compatible, the gfsh output has never been considered an 'API' in terms of > the structure of it's output text. However, I do want to ask that if we > start making changes to these commands, to produce actual JSON results, > will that cause anyone any pain? > > Thoughts / comments? > > --Jens >
[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #905 was SUCCESSFUL (with 2378 tests)
--- Spring Data GemFire > Nightly-ApacheGeode > #905 was successful. --- Scheduled 2380 tests in total. https://build.spring.io/browse/SGF-NAG-905/ -- This message is automatically generated by Atlassian Bamboo
Re: Better support for JSON gfsh results
+1 to improve gfsh and use jackson consistently for all our json parsing On Wed, May 2, 2018 at 3:49 PM, Patrick Rhomberg wrote: > I was under the impression that gfsh console output was intended as a more > "active" interface with an operator. To that end, improved usability and a > more consistent output sounds like a boon to me. > > On Tue, May 1, 2018 at 3:41 PM, Jens Deppe wrote: > > > Hi All, > > > > I'm working on removing our dependency on geode-json (org.json) in favor > of > > Jackson. Initially this work has revolved around refactoring the internal > > results from gfsh commands (nothing that is user-visible). > > > > I'm now looking at the various gfsh 'data' commands (get, put, query and > > locate) and would very much like them to produce more meaningful, (actual > > JSON), structured results. > > > > For example, a get on a region containing a simple 'User' object produces > > this output. > > > > Result : true > > Key Class : java.lang.String > > Key : jondoe > > Value Class : > > org.apache.geode.management.internal.cli.commands. > > GetCommandIntegrationTest.User > > > > This is not very helpful and only really shows that the value, for the > > given key, actually exists. > > > > Querying a PDX object is more informative: > > > > Result : true > > Key Class : java.lang.String > > Key : jondoe > > Value Class : org.apache.geode.pdx.internal.PdxInstanceImpl > > > > username | hashcode > > | > > jondoe | 38de41a9 > > > > This brings me to the actual question. Although our Java API is backwards > > compatible, the gfsh output has never been considered an 'API' in terms > of > > the structure of it's output text. However, I do want to ask that if we > > start making changes to these commands, to produce actual JSON results, > > will that cause anyone any pain? > > > > Thoughts / comments? > > > > --Jens > > >
Broken: jinmeiliao/geode#352 (resultModel - 7fb7c5c)
Build Update for jinmeiliao/geode - Build: #352 Status: Broken Duration: 23 mins and 18 secs Commit: 7fb7c5c (resultModel) Author: Jinmei Liao Message: review changes and fix tests View the changeset: https://github.com/jinmeiliao/geode/compare/b400dbd56abd...7fb7c5c692a8 View the full build log and details: https://travis-ci.org/jinmeiliao/geode/builds/374184286?utm_source=email&utm_medium=notification -- You can configure recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications This email was sent to dev@geode.apache.org (mailto:dev@geode.apache.org) unsubscribe from this list (http://clicks.travis-ci.com/track/unsub.php?u=14313403&id=d29f21129143493898c13ec4f791cb49.J7HZbFy6S8dTlH7tD%2B7uJ8FM8HM%3D&r=https%3A%2F%2Fmandrillapp.com%2Funsub%3Fmd_email%3Ddev%2540geode.apache.org)
