Re: [DISCUSS] GEODE-7241 - make Jar not War?

[Udo Kohlmeyer]

Seems these should have been Jars all along...

On 9/24/19 8:09 PM, Jacob Barrett wrote:

Why publish them as WAR files at all? As they are currently packaged they can't 
be deployed in just any J2EE web container because they lack all the 
dependencies. Sure they look like WAR files internally but they are really 
modules that expect to run in and only in the Geode server. Publishing them as 
a WAR file gives the false impression that they can be consumed by any project 
as a full fledged WAR.

We should make up our own JAR spec based on WAR, perhaps calling it Geode Web 
ARchive or GWAR for short. Yes, I just went there… GWAR!!! 🤘🎸🤘🎸🤘🎸🤘🎸

But seriously, unless it can be deployed in any J2EE web container it shouldn’t 
be considered a WAR.

-Jake


On Sep 24, 2019, at 3:34 PM, Robert Houghton  wrote:

I am working on the change to get the geode-web and geode-web-api war
artifacts published instead of the jars. I have found the
geode-web-management project is also producing a war artifact, in addition
to a jar. Do we want it to be published as well? What is the criterion we
use to decide?

I think this problem was an oversight from the changes PurelyApplied and I
made to the build when we made the publish plugin 'opt-in' instead of
forced by the root project. Easy to publish one or the other, but I am not
qualified to decide whether a war or jar is more appropriate for these
modules.

Thank you,
-Robert

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[John Blum]

Bundling "all" dependencies in a WAR file is a rather subjective topic
since, typically, in practice developers did not bundle things like JDBC
drivers in a WAR file for their Web app.  Common practice was to put
"shared" libs in the Servlet Containers global libs directory (using the
Common ClassLoader) for shared consumption by all Web apps, for better or
worse.

WAR files (like JAR and EAR) are based on "format" (e.g. containing a
WEB-INF/web.xml file, with WEB-INF/classes of the app and possibly libs in
WEB-INF/lib), not simply just deps. As such, by following this format, the
container will consider this a "valid" WAR file.

However, if we are just basing it on libs, then none of the WAR files are
valid by that definition (not even Pulse) because none contain the
necessary Apache Geode libs (e.g. geode-core).  Therefore, none of the WAR
files could stand on their own, not even Pulse.


On Wed, Sep 25, 2019 at 8:17 AM Udo Kohlmeyer  wrote:

> Seems these should have been Jars all along...
>
> On 9/24/19 8:09 PM, Jacob Barrett wrote:
> > Why publish them as WAR files at all? As they are currently packaged
> they can't be deployed in just any J2EE web container because they lack all
> the dependencies. Sure they look like WAR files internally but they are
> really modules that expect to run in and only in the Geode server.
> Publishing them as a WAR file gives the false impression that they can be
> consumed by any project as a full fledged WAR.
> >
> > We should make up our own JAR spec based on WAR, perhaps calling it
> Geode Web ARchive or GWAR for short. Yes, I just went there… GWAR!!!
> 🤘🎸🤘🎸🤘🎸🤘🎸
> >
> > But seriously, unless it can be deployed in any J2EE web container it
> shouldn’t be considered a WAR.
> >
> > -Jake
> >
> >> On Sep 24, 2019, at 3:34 PM, Robert Houghton 
> wrote:
> >>
> >> I am working on the change to get the geode-web and geode-web-api war
> >> artifacts published instead of the jars. I have found the
> >> geode-web-management project is also producing a war artifact, in
> addition
> >> to a jar. Do we want it to be published as well? What is the criterion
> we
> >> use to decide?
> >>
> >> I think this problem was an oversight from the changes PurelyApplied
> and I
> >> made to the build when we made the publish plugin 'opt-in' instead of
> >> forced by the root project. Easy to publish one or the other, but I am
> not
> >> qualified to decide whether a war or jar is more appropriate for these
> >> modules.
> >>
> >> Thank you,
> >> -Robert
>


-- 
-John
john.blum10101 (skype)

Re: New geode-log4j module

[Anthony Baker]

Great writeup, thanks for sharing Kirk!

Anthony


> On Sep 24, 2019, at 10:24 AM, Kirk Lund  wrote:
> 
> All classes that use *log4j-core* have now moved to the new module 
> *geode-log4j
> *on develop. The default log4j2.xml configuration file for Geode Locators
> and Servers has also moved to geode-log4j.
> 
> The first Geode release expected to include this change is 1.11.0.
> 
> The geode-log4j module is included in geode-dependencies.jar so that
> Locators and Servers will continue to use the code and configuration in
> geode-log4j by default. It is also included in the classpath of most
> *integrationTest* and *distributedTest* targets to facilitate non-unit test
> debugging, support *dunit grep for suspect strings*, and also to avoid
> moving or changing tests that involve or require Geode Alerting or Logging
> functionality.
> 
> Precheckin was GREEN before merging to develop, so all Geode tests should
> be unaffected.
> 
> *A. The effects of not having geode-log4j on the classpath
> (client/server/locator) are:*
> 
> 1) Log4j will not be configurable by Geode
> 
> 2) Log4j will print out an error message if not configured by User or Geode
> 
> This is printed out by Apache Log4j (not by Geode):
> 
> ERROR StatusLogger No Log4j 2 configuration file found. Using default
> configuration (logging only errors to the console), or user
> programmatically provided configurations. Set system property
> 'log4j2.debug' to show Log4j 2 internal initialization logging. See
> https://logging.apache.org/log4j/2.x/manual/configuration.html for
> instructions on how to configure Log4j 2
> 
> 3) Geode will not create a log file by default (when starting a server or
> locator using GFSH)
> 
> 4) Logging configuration properties do nothing
> 
> Logging configuration properties include:
> * log-disk-space-limit
> * log-file
> * log-file-size-limit
> * log-level
> 
> 5) Geode Alerts will never be generated
> 
> Geode Alerts are exposed primarily exposed via:
> * DistributedSystemMXBean JMX Notifications
> * Viewable in Pulse (via DistributedSystemMXBean)
> * (Deprecated) Admin API support for Alert Listening
> 
> 6) GFSH commands or options involving Logging and Alerting do nothing
> 
> GFSH commands or options involving Logging and Alerting:
> * alter runtime (log-disk-space-limit, log-file, log-file-size-limit,
> log-level)
> * export logs
> * show log
> * start locator (log-level, redirect-output)
> * start server (log-level, redirect-output)
> 
> *B. The primary reasons a user might not include geode-log4j in their
> classpath:*
> 
> a) User wants to use Logback or other backend instead of log4j-core
> (especially true for users of Spring Boot)
> 
> b) User wants greater control over logging, especially in a client or
> embedded application
> 
> Since Geode uses log4j-api Loggers for its internal logging, swapping out
> log4j-core for logback as the backend imposes a significant performance
> penalty. Although, the logging APIs and backends are interchangeable, using
> the intended backend with its matching API provides the best performance
> for both log4j-api/log4j-core and slf4j/logback.
> 
> *C. Impact on IDE usage*
> 
> IntelliJ projects for Geode should automatically pull in geode-log4j when
> it re-imports from gradle. Note that may see warnings about *"**No Log4j 2
> configuration file found.**"* if you're running a test that doesn't have
> geode-log4j on its classpath.
> 
> For more advanced projects in IntelliJ with additional non-Geode modules,
> you might benefit from using *-Dclasspath* (or other
> proprietary/environment options) in *Gradle VM options*.
> 
> The commit on develop:
> 
> commit efc2362d2bae0877a427ce2c29beae94118d6567
> Author: Kirk Lund 
> Date:   Thu Aug 8 15:17:54 2019 -0700
> 
>GEODE-6964: Move geode log4j core classes to geode-log4j
> 
>Introduce new Logging and Alerting SPIs. Extract all log4j-core code to
>geode-log4j module.
> 
>The geode-core module no longer contains log4j2.xml and no longer has a
>dependency on log4j-core.
> 
>All code that uses log4j-core has moved to the new module geode-log4j.
>The log4j2.xml for Geode now lives in geode-log4j as well. These
>changes ensure that users have better control over logging including
>which backend to use. This should improve user experience when using
>Spring Boot.
> 
>Co-authored-by: Mark Hanson 
> 
> Let me know if there are any questions or if anyone runs into anything
> interesting because of these changes.

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[Anthony Baker]

Udo, 

Can you update GEODE-7241 to help us understand the reason why we need to 
publish geode-web* WARs to maven?  I get that we used to do this but I can’t 
recall why we choose that approach.

There is one request for Pulse on maven (GEODE-6208).

Anthony


> On Sep 24, 2019, at 3:44 PM, Udo Kohlmeyer  wrote:
> 
> Maybe the better question is, WHY are we publishing geode-web and 
> geode-web-api.
> 
> Pulse, from what I remember, could be a standalone deployment. At least that 
> is what I remember.
> 
> Most likely an oversight...
> 
> --Udo
> 
> On 9/24/19 3:38 PM, Robert Houghton wrote:
>> The geode-pulse module also builds a war, but does not publish it. Is this
>> an oversight, or by design?
>> 
>> On Tue, Sep 24, 2019 at 3:34 PM Robert Houghton 
>> wrote:
>> 
>>> I am working on the change to get the geode-web and geode-web-api war
>>> artifacts published instead of the jars. I have found the
>>> geode-web-management project is also producing a war artifact, in addition
>>> to a jar. Do we want it to be published as well? What is the criterion we
>>> use to decide?
>>> 
>>> I think this problem was an oversight from the changes PurelyApplied and I
>>> made to the build when we made the publish plugin 'opt-in' instead of
>>> forced by the root project. Easy to publish one or the other, but I am not
>>> qualified to decide whether a war or jar is more appropriate for these
>>> modules.
>>> 
>>> Thank you,
>>> -Robert
>>> 

[PROPOSAL] adding java-jq to GEODE dependency for testing

[Jinmei Liao]

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

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[John Blum]

Actually, to clarify 2 points.

1. Technically, it is a bit more involved than simply just validating the
"format".  For instance, the web.xml file must be valid and well-formed.
2. There was a reason why the geode-core and other Apache Geode libs were
not bundled in WEB-INF/lib of the WAR files, since then it would create
duplication on the global as well as the WAR file's (isolated) ClassLoader
classpath, particularly for the "embedded" Geode Servlet Container case,
and as such, ClassLoader problems would occur.



On Wed, Sep 25, 2019 at 8:33 AM Anthony Baker  wrote:

> Udo,
>
> Can you update GEODE-7241 to help us understand the reason why we need to
> publish geode-web* WARs to maven?  I get that we used to do this but I
> can’t recall why we choose that approach.
>
> There is one request for Pulse on maven (GEODE-6208).
>
> Anthony
>
>
> > On Sep 24, 2019, at 3:44 PM, Udo Kohlmeyer  wrote:
> >
> > Maybe the better question is, WHY are we publishing geode-web and
> geode-web-api.
> >
> > Pulse, from what I remember, could be a standalone deployment. At least
> that is what I remember.
> >
> > Most likely an oversight...
> >
> > --Udo
> >
> > On 9/24/19 3:38 PM, Robert Houghton wrote:
> >> The geode-pulse module also builds a war, but does not publish it. Is
> this
> >> an oversight, or by design?
> >>
> >> On Tue, Sep 24, 2019 at 3:34 PM Robert Houghton 
> >> wrote:
> >>
> >>> I am working on the change to get the geode-web and geode-web-api war
> >>> artifacts published instead of the jars. I have found the
> >>> geode-web-management project is also producing a war artifact, in
> addition
> >>> to a jar. Do we want it to be published as well? What is the criterion
> we
> >>> use to decide?
> >>>
> >>> I think this problem was an oversight from the changes PurelyApplied
> and I
> >>> made to the build when we made the publish plugin 'opt-in' instead of
> >>> forced by the root project. Easy to publish one or the other, but I am
> not
> >>> qualified to decide whether a war or jar is more appropriate for these
> >>> modules.
> >>>
> >>> Thank you,
> >>> -Robert
> >>>
>
>

-- 
-John
john.blum10101 (skype)

Re: [PROPOSAL] adding java-jq to GEODE dependency for testing

[Anthony Baker]

Sounds good, thanks for the heads up.

Anthony


> On Sep 25, 2019, at 8:37 AM, Jinmei Liao  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

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[Jens Deppe]

I also cannot recall any reason as to the need to *publish* wars.

However, please do not change the files to .jar. To John's point, despite
the lack of some dependent jars, the structure still conforms to a .war
format.

--Jens

On Wed, Sep 25, 2019 at 8:40 AM John Blum  wrote:

> Actually, to clarify 2 points.
>
> 1. Technically, it is a bit more involved than simply just validating the
> "format".  For instance, the web.xml file must be valid and well-formed.
> 2. There was a reason why the geode-core and other Apache Geode libs were
> not bundled in WEB-INF/lib of the WAR files, since then it would create
> duplication on the global as well as the WAR file's (isolated) ClassLoader
> classpath, particularly for the "embedded" Geode Servlet Container case,
> and as such, ClassLoader problems would occur.
>
>
>
> On Wed, Sep 25, 2019 at 8:33 AM Anthony Baker  wrote:
>
> > Udo,
> >
> > Can you update GEODE-7241 to help us understand the reason why we need to
> > publish geode-web* WARs to maven?  I get that we used to do this but I
> > can’t recall why we choose that approach.
> >
> > There is one request for Pulse on maven (GEODE-6208).
> >
> > Anthony
> >
> >
> > > On Sep 24, 2019, at 3:44 PM, Udo Kohlmeyer  wrote:
> > >
> > > Maybe the better question is, WHY are we publishing geode-web and
> > geode-web-api.
> > >
> > > Pulse, from what I remember, could be a standalone deployment. At least
> > that is what I remember.
> > >
> > > Most likely an oversight...
> > >
> > > --Udo
> > >
> > > On 9/24/19 3:38 PM, Robert Houghton wrote:
> > >> The geode-pulse module also builds a war, but does not publish it. Is
> > this
> > >> an oversight, or by design?
> > >>
> > >> On Tue, Sep 24, 2019 at 3:34 PM Robert Houghton  >
> > >> wrote:
> > >>
> > >>> I am working on the change to get the geode-web and geode-web-api war
> > >>> artifacts published instead of the jars. I have found the
> > >>> geode-web-management project is also producing a war artifact, in
> > addition
> > >>> to a jar. Do we want it to be published as well? What is the
> criterion
> > we
> > >>> use to decide?
> > >>>
> > >>> I think this problem was an oversight from the changes PurelyApplied
> > and I
> > >>> made to the build when we made the publish plugin 'opt-in' instead of
> > >>> forced by the root project. Easy to publish one or the other, but I
> am
> > not
> > >>> qualified to decide whether a war or jar is more appropriate for
> these
> > >>> modules.
> > >>>
> > >>> Thank you,
> > >>> -Robert
> > >>>
> >
> >
>
> --
> -John
> john.blum10101 (skype)
>

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[Dan Smith]

I could see value in publishing the war files, if geode will actually pick
up the war file from the classpath and deploy it when these features are
enabled. Udo - it looks like you actually made a change with GEODE-5660 to
enable that?

+1 to making them .GWAR instead :)

-Dan

On Wed, Sep 25, 2019 at 9:07 AM Jens Deppe  wrote:

> I also cannot recall any reason as to the need to *publish* wars.
>
> However, please do not change the files to .jar. To John's point, despite
> the lack of some dependent jars, the structure still conforms to a .war
> format.
>
> --Jens
>
> On Wed, Sep 25, 2019 at 8:40 AM John Blum  wrote:
>
> > Actually, to clarify 2 points.
> >
> > 1. Technically, it is a bit more involved than simply just validating the
> > "format".  For instance, the web.xml file must be valid and well-formed.
> > 2. There was a reason why the geode-core and other Apache Geode libs were
> > not bundled in WEB-INF/lib of the WAR files, since then it would create
> > duplication on the global as well as the WAR file's (isolated)
> ClassLoader
> > classpath, particularly for the "embedded" Geode Servlet Container case,
> > and as such, ClassLoader problems would occur.
> >
> >
> >
> > On Wed, Sep 25, 2019 at 8:33 AM Anthony Baker  wrote:
> >
> > > Udo,
> > >
> > > Can you update GEODE-7241 to help us understand the reason why we need
> to
> > > publish geode-web* WARs to maven?  I get that we used to do this but I
> > > can’t recall why we choose that approach.
> > >
> > > There is one request for Pulse on maven (GEODE-6208).
> > >
> > > Anthony
> > >
> > >
> > > > On Sep 24, 2019, at 3:44 PM, Udo Kohlmeyer  wrote:
> > > >
> > > > Maybe the better question is, WHY are we publishing geode-web and
> > > geode-web-api.
> > > >
> > > > Pulse, from what I remember, could be a standalone deployment. At
> least
> > > that is what I remember.
> > > >
> > > > Most likely an oversight...
> > > >
> > > > --Udo
> > > >
> > > > On 9/24/19 3:38 PM, Robert Houghton wrote:
> > > >> The geode-pulse module also builds a war, but does not publish it.
> Is
> > > this
> > > >> an oversight, or by design?
> > > >>
> > > >> On Tue, Sep 24, 2019 at 3:34 PM Robert Houghton <
> rhough...@pivotal.io
> > >
> > > >> wrote:
> > > >>
> > > >>> I am working on the change to get the geode-web and geode-web-api
> war
> > > >>> artifacts published instead of the jars. I have found the
> > > >>> geode-web-management project is also producing a war artifact, in
> > > addition
> > > >>> to a jar. Do we want it to be published as well? What is the
> > criterion
> > > we
> > > >>> use to decide?
> > > >>>
> > > >>> I think this problem was an oversight from the changes
> PurelyApplied
> > > and I
> > > >>> made to the build when we made the publish plugin 'opt-in' instead
> of
> > > >>> forced by the root project. Easy to publish one or the other, but I
> > am
> > > not
> > > >>> qualified to decide whether a war or jar is more appropriate for
> > these
> > > >>> modules.
> > > >>>
> > > >>> Thank you,
> > > >>> -Robert
> > > >>>
> > >
> > >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[Juan José Ramos]

+1 to Jens and John comments.
I'm 100% sure some of our users certainly deploy the *war* file (at least
the *PULSE* one) to external web application servers.
Cheers.

On Wed, Sep 25, 2019 at 5:07 PM Jens Deppe  wrote:

> I also cannot recall any reason as to the need to *publish* wars.
>
> However, please do not change the files to .jar. To John's point, despite
> the lack of some dependent jars, the structure still conforms to a .war
> format.
>
> --Jens
>
> On Wed, Sep 25, 2019 at 8:40 AM John Blum  wrote:
>
> > Actually, to clarify 2 points.
> >
> > 1. Technically, it is a bit more involved than simply just validating the
> > "format".  For instance, the web.xml file must be valid and well-formed.
> > 2. There was a reason why the geode-core and other Apache Geode libs were
> > not bundled in WEB-INF/lib of the WAR files, since then it would create
> > duplication on the global as well as the WAR file's (isolated)
> ClassLoader
> > classpath, particularly for the "embedded" Geode Servlet Container case,
> > and as such, ClassLoader problems would occur.
> >
> >
> >
> > On Wed, Sep 25, 2019 at 8:33 AM Anthony Baker  wrote:
> >
> > > Udo,
> > >
> > > Can you update GEODE-7241 to help us understand the reason why we need
> to
> > > publish geode-web* WARs to maven?  I get that we used to do this but I
> > > can’t recall why we choose that approach.
> > >
> > > There is one request for Pulse on maven (GEODE-6208).
> > >
> > > Anthony
> > >
> > >
> > > > On Sep 24, 2019, at 3:44 PM, Udo Kohlmeyer  wrote:
> > > >
> > > > Maybe the better question is, WHY are we publishing geode-web and
> > > geode-web-api.
> > > >
> > > > Pulse, from what I remember, could be a standalone deployment. At
> least
> > > that is what I remember.
> > > >
> > > > Most likely an oversight...
> > > >
> > > > --Udo
> > > >
> > > > On 9/24/19 3:38 PM, Robert Houghton wrote:
> > > >> The geode-pulse module also builds a war, but does not publish it.
> Is
> > > this
> > > >> an oversight, or by design?
> > > >>
> > > >> On Tue, Sep 24, 2019 at 3:34 PM Robert Houghton <
> rhough...@pivotal.io
> > >
> > > >> wrote:
> > > >>
> > > >>> I am working on the change to get the geode-web and geode-web-api
> war
> > > >>> artifacts published instead of the jars. I have found the
> > > >>> geode-web-management project is also producing a war artifact, in
> > > addition
> > > >>> to a jar. Do we want it to be published as well? What is the
> > criterion
> > > we
> > > >>> use to decide?
> > > >>>
> > > >>> I think this problem was an oversight from the changes
> PurelyApplied
> > > and I
> > > >>> made to the build when we made the publish plugin 'opt-in' instead
> of
> > > >>> forced by the root project. Easy to publish one or the other, but I
> > am
> > > not
> > > >>> qualified to decide whether a war or jar is more appropriate for
> > these
> > > >>> modules.
> > > >>>
> > > >>> Thank you,
> > > >>> -Robert
> > > >>>
> > >
> > >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>


-- 
Juan José Ramos Cassella
Senior Software Engineer
Email: jra...@pivotal.io

Re: [PROPOSAL] adding java-jq to GEODE dependency for testing

[Dan Smith]

+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  wrote:

> Sounds good, thanks for the heads up.
>
> Anthony
>
>
> > On Sep 25, 2019, at 8:37 AM, Jinmei Liao  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
>
>

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[Jacob Barrett]

> On Sep 25, 2019, at 9:33 AM, Dan Smith  wrote:
> 
> +1 to making them .GWAR instead :)

Ok I think this constitutes consensus on GWAR!  ;)

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[Charlie Black]

Just incase here is the docs on pushing the war:
https://geode.apache.org/docs/guide/16/tools_modules/pulse/pulse-hosted.html

On Wed, Sep 25, 2019 at 9:53 AM Jacob Barrett  wrote:

>
>
> > On Sep 25, 2019, at 9:33 AM, Dan Smith  wrote:
> >
> > +1 to making them .GWAR instead :)
>
> Ok I think this constitutes consensus on GWAR!  ;)
>


-- 
Charlie Black | cbl...@pivotal.io

Re: [PROPOSAL] adding java-jq to GEODE dependency for testing

[Owen Nichols]

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  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  wrote:
> 
>> Sounds good, thanks for the heads up.
>> 
>> Anthony
>> 
>> 
>>> On Sep 25, 2019, at 8:37 AM, Jinmei Liao  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
>> 
>> 

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[Udo Kohlmeyer]

@Anthony. Ticket was updated.. In a nutshell, to run integration tests, 
using the REST endpoints, requires the starting of the server with and 
embedded web-server.


As all tests run on dependency management only and don't have access to 
a downloaded product, the HTTP endpoints are not part of the dependency. 
These are added in by including the WAR files from mavenCentral.


As @Dan pointed out, GEODE-5660 enabled this behavior.

I think this approach might actually even help with the testing of the 
REST Controller in the Geode codebase itself.


--Udo

On 9/25/19 8:32 AM, Anthony Baker wrote:

Udo,

Can you update GEODE-7241 to help us understand the reason why we need to 
publish geode-web* WARs to maven?  I get that we used to do this but I can’t 
recall why we choose that approach.

There is one request for Pulse on maven (GEODE-6208).

Anthony



On Sep 24, 2019, at 3:44 PM, Udo Kohlmeyer  wrote:

Maybe the better question is, WHY are we publishing geode-web and geode-web-api.

Pulse, from what I remember, could be a standalone deployment. At least that is 
what I remember.

Most likely an oversight...

--Udo

On 9/24/19 3:38 PM, Robert Houghton wrote:

The geode-pulse module also builds a war, but does not publish it. Is this
an oversight, or by design?

On Tue, Sep 24, 2019 at 3:34 PM Robert Houghton 
wrote:


I am working on the change to get the geode-web and geode-web-api war
artifacts published instead of the jars. I have found the
geode-web-management project is also producing a war artifact, in addition
to a jar. Do we want it to be published as well? What is the criterion we
use to decide?

I think this problem was an oversight from the changes PurelyApplied and I
made to the build when we made the publish plugin 'opt-in' instead of
forced by the root project. Easy to publish one or the other, but I am not
qualified to decide whether a war or jar is more appropriate for these
modules.

Thank you,
-Robert

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[Anthony Baker]

Thanks for the reminder.  If these files are required to start a geode member, 
I agree they should be published artifacts.  Perhaps there’s a better way to 
pull them in…but this seems like the best option for now.

Anthony


> On Sep 25, 2019, at 10:22 AM, Udo Kohlmeyer  wrote:
> 
> @Anthony. Ticket was updated.. In a nutshell, to run integration tests, using 
> the REST endpoints, requires the starting of the server with and embedded 
> web-server.
> 
> As all tests run on dependency management only and don't have access to a 
> downloaded product, the HTTP endpoints are not part of the dependency. These 
> are added in by including the WAR files from mavenCentral.
> 
> As @Dan pointed out, GEODE-5660 enabled this behavior.
> 
> I think this approach might actually even help with the testing of the REST 
> Controller in the Geode codebase itself.
> 
> --Udo

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[John Blum]

It occurred to me after *Charlie* shared the link to installing *Pulse* in
a standalone Servlet Container (e.g. Apache Tomcat) that we don't properly
describe how to handle the Geode dependencies (e.g. geode-core).  Again,
this is not bundled as part of the Geode WAR files.

-1 to publishing a GWAR file.  These are still valid WAR files regardless
of the dependencies they provide or don't provide (which is a documentation
concern in my mind).


On Wed, Sep 25, 2019 at 10:53 AM Anthony Baker  wrote:

> Thanks for the reminder.  If these files are required to start a geode
> member, I agree they should be published artifacts.  Perhaps there’s a
> better way to pull them in…but this seems like the best option for now.
>
> Anthony
>
>
> > On Sep 25, 2019, at 10:22 AM, Udo Kohlmeyer 
> wrote:
> >
> > @Anthony. Ticket was updated.. In a nutshell, to run integration tests,
> using the REST endpoints, requires the starting of the server with and
> embedded web-server.
> >
> > As all tests run on dependency management only and don't have access to
> a downloaded product, the HTTP endpoints are not part of the dependency.
> These are added in by including the WAR files from mavenCentral.
> >
> > As @Dan pointed out, GEODE-5660 enabled this behavior.
> >
> > I think this approach might actually even help with the testing of the
> REST Controller in the Geode codebase itself.
> >
> > --Udo
>
>

-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[Jacob Barrett]

> On Sep 25, 2019, at 11:01 AM, John Blum  wrote:
> -1 to publishing a GWAR file.  These are still valid WAR files regardless
> of the dependencies they provide or don't provide (which is a documentation
> concern in my mind).

Just to be really clear, GWAR was a joke and a reference to the popular 80/90s 
band. 🤘🎸🤘🎸🤘🎸🤘🎸

-Jake

Re: [PROPOSAL] adding java-jq to GEODE dependency for testing

[Jinmei Liao]

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  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  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  wrote:
> >
> >> Sounds good, thanks for the heads up.
> >>
> >> Anthony
> >>
> >>
> >>> On Sep 25, 2019, at 8:37 AM, Jinmei Liao  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

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[Udo Kohlmeyer]

So it seems there is consensus around jar vs war. WAR's win by nose. 
(until we can find a more creative way to expose said artifacts)


That said, do we need to start another thread about fixing 1.8.x or 1.9.x?

I'm already considering proposing that GEODE-7241 is included into 
1.9.2, as that patch release is already discussed to backport GEODE-7121.


--Udo

On 9/25/19 10:53 AM, Anthony Baker wrote:

Thanks for the reminder.  If these files are required to start a geode member, 
I agree they should be published artifacts.  Perhaps there’s a better way to 
pull them in…but this seems like the best option for now.

Anthony



On Sep 25, 2019, at 10:22 AM, Udo Kohlmeyer  wrote:

@Anthony. Ticket was updated.. In a nutshell, to run integration tests, using 
the REST endpoints, requires the starting of the server with and embedded 
web-server.

As all tests run on dependency management only and don't have access to a 
downloaded product, the HTTP endpoints are not part of the dependency. These 
are added in by including the WAR files from mavenCentral.

As @Dan pointed out, GEODE-5660 enabled this behavior.

I think this approach might actually even help with the testing of the REST 
Controller in the Geode codebase itself.

--Udo

Re: [DISCUSS] - Cutting of release 1.9.2

[Udo Kohlmeyer]

It seems there is consensus to cut a 1.9.2 release to include GEODE-7121.

--Udo

On 9/20/19 3:34 PM, Jens Deppe wrote:

+1 for creating a 1.9.2 release with this fix.

On Fri, Sep 20, 2019 at 2:00 PM Udo Kohlmeyer  wrote:


John, thank you!

You are correct, not sure what I was thinking.. Geode 1.9.x IS used by
SDG 2.2

On 9/20/19 1:11 PM, John Blum wrote:

Correction to *Udo's* comments!

SDG Moore/2.2 is based on Apache Geode 1.9, NOT SDG Lovelace/2.1 (which

is

based on Apache Geode 1.6).

You can review the version compatibility matrix beginning with SBDG,

here (
https://github.com/spring-projects/spring-boot-data-geode/wiki/Spring-Boot-for-Apache-Geode-and-Pivotal-GemFire-Version-Compatibility-Matrix

).

On Fri, Sep 20, 2019 at 1:09 PM John Blum  wrote:


Hi Kirk - SDG 2.3/Neuman, which is only after SDG 2.2/Moore GAs, which

is

tentatively scheduled for Monday, Sept. 30th.

On Fri, Sep 20, 2019 at 1:01 PM Kirk Lund  wrote:


Hi Udo, SDG cannot upgrade to Geode 1.10.x until which version? SDG

2.2.0?

On Fri, Sep 20, 2019 at 12:45 PM Udo Kohlmeyer  wrote:


Hi there Geode Dev's,

I would like to propose a release for Geode 1.9.x that includes
https://issues.apache.org/jira/browse/GEODE-7121.

This is an issue that is current in the 1.9.x branch, which is used by
Spring Data Geode 2.1.10 <

https://spring.io/projects/spring-data-geode

.

This issue can cause an application using Spring Data Geode to

bootstrap

GEODE to deadlock upon start up.

This is critical system's issue and given that Spring Data Geode

cannot

change its underlying dependency to 1.10+, would require this fix to

be

back-ported to the 1.9 branch.

--Udo



--
-John
john.blum10101 (skype)

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[Anthony Baker]

Since SBDG is fixed to Geode 1.9.x I can see an argument for backporting to 
there.  I’m personally not as excited about a new 1.8 patch release but I’m 
open to hearing your ideas :-)

Anthony


> On Sep 25, 2019, at 11:46 AM, Udo Kohlmeyer  wrote:
> 
> So it seems there is consensus around jar vs war. WAR's win by nose. (until 
> we can find a more creative way to expose said artifacts)
> 
> That said, do we need to start another thread about fixing 1.8.x or 1.9.x?
> 
> I'm already considering proposing that GEODE-7241 is included into 1.9.2, as 
> that patch release is already discussed to backport GEODE-7121.
> 
> --Udo
> 
> On 9/25/19 10:53 AM, Anthony Baker wrote:
>> Thanks for the reminder.  If these files are required to start a geode 
>> member, I agree they should be published artifacts.  Perhaps there’s a 
>> better way to pull them in…but this seems like the best option for now.
>> 
>> Anthony
>> 
>> 
>>> On Sep 25, 2019, at 10:22 AM, Udo Kohlmeyer  wrote:
>>> 
>>> @Anthony. Ticket was updated.. In a nutshell, to run integration tests, 
>>> using the REST endpoints, requires the starting of the server with and 
>>> embedded web-server.
>>> 
>>> As all tests run on dependency management only and don't have access to a 
>>> downloaded product, the HTTP endpoints are not part of the dependency. 
>>> These are added in by including the WAR files from mavenCentral.
>>> 
>>> As @Dan pointed out, GEODE-5660 enabled this behavior.
>>> 
>>> I think this approach might actually even help with the testing of the REST 
>>> Controller in the Geode codebase itself.
>>> 
>>> --Udo

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[Udo Kohlmeyer]

@Anthony, you must have missed the LACK OF excitement in that 
question... 1.8.x should stay as is... I was merely asking the question.


--Udo

On 9/25/19 11:58 AM, Anthony Baker wrote:

Since SBDG is fixed to Geode 1.9.x I can see an argument for backporting to 
there.  I’m personally not as excited about a new 1.8 patch release but I’m 
open to hearing your ideas :-)

Anthony



On Sep 25, 2019, at 11:46 AM, Udo Kohlmeyer  wrote:

So it seems there is consensus around jar vs war. WAR's win by nose. (until we 
can find a more creative way to expose said artifacts)

That said, do we need to start another thread about fixing 1.8.x or 1.9.x?

I'm already considering proposing that GEODE-7241 is included into 1.9.2, as 
that patch release is already discussed to backport GEODE-7121.

--Udo

On 9/25/19 10:53 AM, Anthony Baker wrote:

Thanks for the reminder.  If these files are required to start a geode member, 
I agree they should be published artifacts.  Perhaps there’s a better way to 
pull them in…but this seems like the best option for now.

Anthony



On Sep 25, 2019, at 10:22 AM, Udo Kohlmeyer  wrote:

@Anthony. Ticket was updated.. In a nutshell, to run integration tests, using 
the REST endpoints, requires the starting of the server with and embedded 
web-server.

As all tests run on dependency management only and don't have access to a 
downloaded product, the HTTP endpoints are not part of the dependency. These 
are added in by including the WAR files from mavenCentral.

As @Dan pointed out, GEODE-5660 enabled this behavior.

I think this approach might actually even help with the testing of the REST 
Controller in the Geode codebase itself.

--Udo

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[Jacob Barrett]

-1 for updating previous releases or merging into the current release. I see no 
overwhelming need to have these published so that a downstream project can 
subvert the prescribed why of starting a server with all its dependencies. A 
workaround to this issue is to depend on the full distribution tgz and use gfsh 
or geode-dependencies.jar to start things up.

-Jake

> On Sep 25, 2019, at 11:46 AM, Udo Kohlmeyer  wrote:
> 
> So it seems there is consensus around jar vs war. WAR's win by nose. (until 
> we can find a more creative way to expose said artifacts)
> 
> That said, do we need to start another thread about fixing 1.8.x or 1.9.x?
> 
> I'm already considering proposing that GEODE-7241 is included into 1.9.2, as 
> that patch release is already discussed to backport GEODE-7121.
> 
> --Udo
> 
> On 9/25/19 10:53 AM, Anthony Baker wrote:
>> Thanks for the reminder.  If these files are required to start a geode 
>> member, I agree they should be published artifacts.  Perhaps there’s a 
>> better way to pull them in…but this seems like the best option for now.
>> 
>> Anthony
>> 
>> 
>>> On Sep 25, 2019, at 10:22 AM, Udo Kohlmeyer  wrote:
>>> 
>>> @Anthony. Ticket was updated.. In a nutshell, to run integration tests, 
>>> using the REST endpoints, requires the starting of the server with and 
>>> embedded web-server.
>>> 
>>> As all tests run on dependency management only and don't have access to a 
>>> downloaded product, the HTTP endpoints are not part of the dependency. 
>>> These are added in by including the WAR files from mavenCentral.
>>> 
>>> As @Dan pointed out, GEODE-5660 enabled this behavior.
>>> 
>>> I think this approach might actually even help with the testing of the REST 
>>> Controller in the Geode codebase itself.
>>> 
>>> --Udo

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[Udo Kohlmeyer]

@Jake, whilst I agree with your statement that there is a preference 
that sers use GFSH to manage their clusters. With that statement are you 
also making a blanket statement we should remove the exposed public 
API's we expose in GEODE to start a Client/Server/Locator?


IF the expected usage of the product is to download it and not use 
dependency management, should we then also remove `geode-core`, 
`geode-wan`, `geode-lucene` artifacts, as all of these would also be 
within the dependencies listed in the geode-dependecies.jar?


It DOES sound counter productive and in essence a little backwards, but 
if our "prescribed" approach to interact/bootstrap/configure/manage 
Geode is to use GFSH, then we should remove all other temptations.


--Udo

On 9/25/19 12:10 PM, Jacob Barrett wrote:


-1 for updating previous releases or merging into the current release. I see no 
overwhelming need to have these published so that a downstream project can 
subvert the prescribed why of starting a server with all its dependencies. A 
workaround to this issue is to depend on the full distribution tgz and use gfsh 
or geode-dependencies.jar to start things up.

-Jake


On Sep 25, 2019, at 11:46 AM, Udo Kohlmeyer  wrote:

So it seems there is consensus around jar vs war. WAR's win by nose. (until we 
can find a more creative way to expose said artifacts)

That said, do we need to start another thread about fixing 1.8.x or 1.9.x?

I'm already considering proposing that GEODE-7241 is included into 1.9.2, as 
that patch release is already discussed to backport GEODE-7121.

--Udo

On 9/25/19 10:53 AM, Anthony Baker wrote:

Thanks for the reminder.  If these files are required to start a geode member, 
I agree they should be published artifacts.  Perhaps there’s a better way to 
pull them in…but this seems like the best option for now.

Anthony



On Sep 25, 2019, at 10:22 AM, Udo Kohlmeyer  wrote:

@Anthony. Ticket was updated.. In a nutshell, to run integration tests, using 
the REST endpoints, requires the starting of the server with and embedded 
web-server.

As all tests run on dependency management only and don't have access to a 
downloaded product, the HTTP endpoints are not part of the dependency. These 
are added in by including the WAR files from mavenCentral.

As @Dan pointed out, GEODE-5660 enabled this behavior.

I think this approach might actually even help with the testing of the REST 
Controller in the Geode codebase itself.

--Udo

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[Jacob Barrett]

Udo,

I didn’t say we shouldn’t fix it for the future. I said I don’t believe it 
warrants a backport and a patch release.

-Jake

Re: [VOTE] Apache Geode 1.10.0.RC2

[Owen Nichols]

+0

✅ verified that apache-geode-native-1.10.0-src.tar.gz extracts with a versioned 
top-level directory
✅ set up a small cluster (2 locators, 3 servers, 1 client, ssl enabled) and ran 
some simple puts, gets, and CQ.
⚠️ I cannot give “+1" yet because the release notes 

 appear unfinished.  For new features, a few words about why it’s awesome would 
be nice.  AEQ-pause isn’t even mentioned at all. And maybe highlight the “top 
10” bug fixes?  See release notes for 1.9.0, 1.8.0, 1.7.0, 1.6.0, 1.5.0, 1.4.0, 
1.3.0, or 1.2.0 for examples of the level of detail I would hope to see when a 
new minor release is announced.

Quibbles:
⚠️ to run my spring boot client for above test, I had to manually add compile 
'io.micrometer:micrometer-core:1.2.0' , otherwise local region creation blows 
up with “java.lang.NoSuchMethodError” due to spring-boot-starter pulling in 
micrometer 1.0.3 by default.  This never happened with previous versions.  Not 
sure if this is outside Geode’s control, but it felt like a poor out-of-the-box 
experience... 

-Owen

> On Sep 23, 2019, at 12:57 PM, Anthony Baker  wrote:
> 
> +1
> 
> 
> Reviewed:
> 
> - Signatures and hashes
> - LICENSE and NOTICE
> - No binaries in source distribution
> - Builds from source
> 
> 
> Quibbles:
> 
> - Let’s include geode-benchmarks/ next release
> - It would be more awesome if geode-native extracts into a directory with a 
> versioned name (e.g. apache-geode-native-1.10.0/)
> - geode-examples is the only distribution that provides a zip format…is that 
> needed?
> 
> Anthony
> 
> 
>> On Sep 20, 2019, at 9:26 AM, Dick Cavender  wrote:
>> 
>> Hello Geode dev community,
>> 
>> This is a release candidate for Apache Geode, version 1.10.0.RC2.
>> Thanks to all the community members for their contributions to this release!
>> 
>> Please do a review and give your feedback including the checks performed.
>> The voting deadline is *3PM PST Wed, September 25 2019*.
>> 
>> This candidate has passed RC Qualification checks (NEW) which can be found
>> at:
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-10-0-rc
>> 
>> Release notes can be found at:
>> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.10.0
>> 
>> Please note that we are voting upon the source tags: *rel/v1.10.0.RC2*
>> 
>> Apache Geode:
>> https://github.com/apache/geode/tree/rel/v1.10.0.RC2
>> Apache Geode examples:
>> https://github.com/apache/geode-examples/tree/rel/v1.10.0.RC2
>> Apache Geode native:
>> https://github.com/apache/geode-native/tree/rel/v1.10.0.RC2
>> 
>> Source and binary files:
>> https://dist.apache.org/repos/dist/dev/geode/1.10.0.RC2/
>> 
>> Maven staging repo:
>> https://repository.apache.org/content/repositories/orgapachegeode-1059
>> 
>> Geode's KEYS file containing PGP keys we use to sign the release:
>> https://github.com/apache/geode/blob/develop/KEYS
>> 
>> PS: Command to run geode-examples: ./gradlew -PgeodeReleaseUrl=
>> https://dist.apache.org/repos/dist/dev/geode/1.10.0.RC2
>> -PgeodeRepositoryUrl=
>> https://repository.apache.org/content/repositories/orgapachegeode-1059
>> build runAll
>> 
>> Regards
>> Dick Cavender
> 

Re: [VOTE] Apache Geode 1.10.0.RC2

[Jacob Barrett]

> On Sep 25, 2019, at 12:26 PM, Owen Nichols  wrote:
> 
> ⚠️ to run my spring boot client for above test, I had to manually add compile 
> 'io.micrometer:micrometer-core:1.2.0' , otherwise local region creation blows 
> up with “java.lang.NoSuchMethodError” due to spring-boot-starter pulling in 
> micrometer 1.0.3 by default.  This never happened with previous versions.  
> Not sure if this is outside Geode’s control, but it felt like a poor 
> out-of-the-box experience... 

Is your spring app including geode via maven/gradle dependency management? This 
may be pointing to a greater issue with dependency exports in the new release's 
POM. 

-Jake

Re: [VOTE] Apache Geode 1.10.0.RC2

[Owen Nichols]

My build.gradle is pretty simple:

repositories {
  mavenCentral()
  maven {
url 'https://repository.apache.org/content/repositories/orgapachegeode-1059'
  }
}

dependencies {
  compile('org.springframework.boot:spring-boot-starter')
  compile 'org.apache.geode:geode-core:1.10.0'
  compile 'org.apache.geode:geode-cq:1.10.0'
}


> On Sep 25, 2019, at 12:29 PM, Jacob Barrett  wrote:
> 
> 
> 
>> On Sep 25, 2019, at 12:26 PM, Owen Nichols  wrote:
>> 
>> ⚠️ to run my spring boot client for above test, I had to manually add 
>> compile 'io.micrometer:micrometer-core:1.2.0' , otherwise local region 
>> creation blows up with “java.lang.NoSuchMethodError” due to 
>> spring-boot-starter pulling in micrometer 1.0.3 by default.  This never 
>> happened with previous versions.  Not sure if this is outside Geode’s 
>> control, but it felt like a poor out-of-the-box experience... 
> 
> Is your spring app including geode via maven/gradle dependency management? 
> This may be pointing to a greater issue with dependency exports in the new 
> release's POM. 
> 
> -Jake
> 

Spring Boot with Geode 1.10

[Jacob Barrett]

Changing subject…


Try
dependencies {
implementation(platform(‘org.apache.geode:geode-client-bom:1.10.0’))
implementation(‘org.apache.geode:geode-core’)
implementation('org.apache.geode:geode-cq’)
}

Does that make a difference?


> On Sep 25, 2019, at 12:35 PM, Owen Nichols  wrote:
> 
> My build.gradle is pretty simple:
> 
> repositories {
>  mavenCentral()
>  maven {
>url 
> 'https://repository.apache.org/content/repositories/orgapachegeode-1059'
>  }
> }
> 
> dependencies {
>  compile('org.springframework.boot:spring-boot-starter')
>  compile 'org.apache.geode:geode-core:1.10.0'
>  compile 'org.apache.geode:geode-cq:1.10.0'
> }
> 
> 
>> On Sep 25, 2019, at 12:29 PM, Jacob Barrett  wrote:
>> 
>> 
>> 
>>> On Sep 25, 2019, at 12:26 PM, Owen Nichols  wrote:
>>> 
>>> ⚠️ to run my spring boot client for above test, I had to manually add 
>>> compile 'io.micrometer:micrometer-core:1.2.0' , otherwise local region 
>>> creation blows up with “java.lang.NoSuchMethodError” due to 
>>> spring-boot-starter pulling in micrometer 1.0.3 by default.  This never 
>>> happened with previous versions.  Not sure if this is outside Geode’s 
>>> control, but it felt like a poor out-of-the-box experience... 
>> 
>> Is your spring app including geode via maven/gradle dependency management? 
>> This may be pointing to a greater issue with dependency exports in the new 
>> release's POM. 
>> 
>> -Jake
>> 
> 

Re: [PROPOSAL] adding java-jq to GEODE dependency for testing

[Owen Nichols]

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__ 
 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  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  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  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  wrote:
>>> 
 Sounds good, thanks for the heads up.
 
 Anthony
 
 
> On Sep 25, 2019, at 8:37 AM, Jinmei Liao  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

Re: [DISCUSS] GEODE-7241 - make Jar not War?

[John Blum]

@Jake - Ah, indeed it was https://en.wikipedia.org/wiki/Gwar.  I never
heard of them until now. Gotta love the 80s Rock/Heavy Metal Era.

On Wed, Sep 25, 2019 at 12:22 PM Jacob Barrett  wrote:

> Udo,
>
> I didn’t say we shouldn’t fix it for the future. I said I don’t believe it
> warrants a backport and a patch release.
>
> -Jake
>
>

-- 
-John
john.blum10101 (skype)

Re: Spring Boot with Geode 1.10

[Owen Nichols]

This still pulls in micrometer 1.0.3

dependencies {
  compile('org.springframework.boot:spring-boot-starter')
  
  implementation(platform('org.apache.geode:geode-client-bom:1.10.0'))
  implementation('org.apache.geode:geode-core')
  implementation('org.apache.geode:geode-cq')

  testCompile('org.springframework.boot:spring-boot-starter-test')
  testCompile 'junit:junit:4.+'
}


> On Sep 25, 2019, at 12:43 PM, Jacob Barrett  wrote:
> 
> Changing subject…
> 
> 
> Try
> dependencies {
>   implementation(platform(‘org.apache.geode:geode-client-bom:1.10.0’))
>   implementation(‘org.apache.geode:geode-core’)
>   implementation('org.apache.geode:geode-cq’)
> }
> 
> Does that make a difference?
> 
> 
>> On Sep 25, 2019, at 12:35 PM, Owen Nichols  wrote:
>> 
>> My build.gradle is pretty simple:
>> 
>> repositories {
>> mavenCentral()
>> maven {
>>   url 
>> 'https://repository.apache.org/content/repositories/orgapachegeode-1059'
>> }
>> }
>> 
>> dependencies {
>> compile('org.springframework.boot:spring-boot-starter')
>> compile 'org.apache.geode:geode-core:1.10.0'
>> compile 'org.apache.geode:geode-cq:1.10.0'
>> }
>> 
>> 
>>> On Sep 25, 2019, at 12:29 PM, Jacob Barrett  wrote:
>>> 
>>> 
>>> 
 On Sep 25, 2019, at 12:26 PM, Owen Nichols  wrote:
 
 ⚠️ to run my spring boot client for above test, I had to manually add 
 compile 'io.micrometer:micrometer-core:1.2.0' , otherwise local region 
 creation blows up with “java.lang.NoSuchMethodError” due to 
 spring-boot-starter pulling in micrometer 1.0.3 by default.  This never 
 happened with previous versions.  Not sure if this is outside Geode’s 
 control, but it felt like a poor out-of-the-box experience... 
>>> 
>>> Is your spring app including geode via maven/gradle dependency management? 
>>> This may be pointing to a greater issue with dependency exports in the new 
>>> release's POM. 
>>> 
>>> -Jake
>>> 
>> 
> 

Re: Spring Boot with Geode 1.10

[Jacob Barrett]

Offline discovery…

Looking at ./gradlew dependencies shows that micrometer is being downgraded by 
spring dependency plugin to 1.0.3. Attempting different versions of spring boot.

-Jake
 

> On Sep 25, 2019, at 1:04 PM, Owen Nichols  wrote:
> 
> This still pulls in micrometer 1.0.3
> 
> dependencies {
>  compile('org.springframework.boot:spring-boot-starter')
> 
>  implementation(platform('org.apache.geode:geode-client-bom:1.10.0'))
>  implementation('org.apache.geode:geode-core')
>  implementation('org.apache.geode:geode-cq')
> 
>  testCompile('org.springframework.boot:spring-boot-starter-test')
>  testCompile 'junit:junit:4.+'
> }
> 
> 
>> On Sep 25, 2019, at 12:43 PM, Jacob Barrett  wrote:
>> 
>> Changing subject…
>> 
>> 
>> Try
>> dependencies {
>>  implementation(platform(‘org.apache.geode:geode-client-bom:1.10.0’))
>>  implementation(‘org.apache.geode:geode-core’)
>>  implementation('org.apache.geode:geode-cq’)
>> }
>> 
>> Does that make a difference?
>> 
>> 
>>> On Sep 25, 2019, at 12:35 PM, Owen Nichols  wrote:
>>> 
>>> My build.gradle is pretty simple:
>>> 
>>> repositories {
>>> mavenCentral()
>>> maven {
>>>  url 
>>> 'https://repository.apache.org/content/repositories/orgapachegeode-1059'
>>> }
>>> }
>>> 
>>> dependencies {
>>> compile('org.springframework.boot:spring-boot-starter')
>>> compile 'org.apache.geode:geode-core:1.10.0'
>>> compile 'org.apache.geode:geode-cq:1.10.0'
>>> }
>>> 
>>> 
 On Sep 25, 2019, at 12:29 PM, Jacob Barrett  wrote:
 
 
 
> On Sep 25, 2019, at 12:26 PM, Owen Nichols  wrote:
> 
> ⚠️ to run my spring boot client for above test, I had to manually add 
> compile 'io.micrometer:micrometer-core:1.2.0' , otherwise local region 
> creation blows up with “java.lang.NoSuchMethodError” due to 
> spring-boot-starter pulling in micrometer 1.0.3 by default.  This never 
> happened with previous versions.  Not sure if this is outside Geode’s 
> control, but it felt like a poor out-of-the-box experience... 
 
 Is your spring app including geode via maven/gradle dependency management? 
 This may be pointing to a greater issue with dependency exports in the new 
 release's POM. 
 
 -Jake
 
>>> 
>> 
> 

Re: Spring Boot with Geode 1.10

[John Blum]

There is no version of Spring Boot (SBDG) currently built on Apache Geode
1.10 at the moment.

In general, you should understand 2 things.


1. First, the Apache Geode version that Spring Boot, or SBDG, is dependent
on is indirectly (transitively) determined by upstream dependencies.

SBDG -> Spring Boot -> SDG -> Apache Geode.

E.g. SDG Moore/2.2 pulls in Apache Geode 1.9.x.  SBDG 1.2 pulls in SDG
Moore/2.2.  Spring Boot 2.2 also pulls in SD[G] Moore/2.2. Both SBDG and
Spring Boot must agree on the version of SD[G] that they use.  So, it is
not a coincidence that both SBDG (1.2) and Spring Boot (2.2) pull in SD
Moore/2.2 and are therefore both (indirectly) dependent on Apache Geode 1.9.

E.g. SDG Lovelace/2.1 pulls in Apache Geode 1.6.  SBDG 1.1 pulls in SDG
Lovelace/2.1.  Spring Boot 2.1 also pulls in SD[G] Lovelace/2.2.  Both SBDG
and Spring Boot must agree on the version of SD[G] that they use in 1.1/2.1
respectively.


2. Next, Spring Boot's dependency management extends beyond simply Spring
Data, to other (upstream, from Boot) Spring projects/dependencies (e.g.
Spring Framework, Spring Batch, Spring Integration, Spring Security, etc)
as well as 3rd party libraries.


Any, and I mean ANY (!) properly managed Java project, not just Spring,
must manage dependencies in a consistent and responsible way to avoid
conflicts that would cause end users issues (especially with their
applications that consume our dependencies) given multiple transitive
dependencies are likely to share the same dependencies (e.g. logging is
always usually the most common example).

You should not assume you can just simply change dependencies at random
(e.g. I will use Spring Boot 2.2 with SBDG 1.1, or change the Micrometer
versions, or whatever).  The stars must align so to speak, and for good
reason.  Again, this is why tools like Apache Maven exists in the first
place.

In some cases, this might work, but it is not normal to think you can do
this in general, and most of the Java community understands this.  It must
be a conscious choice and users are aware that they must manually
exclude/override a dependency and/or declare their own dependencyManagement
section in their application POM to declare their choices.

Anyway, this 1 of the many reasons why Spring Boot so eloquently handles
this concern for you.

SDG Neuman/2.3 will be based on Apache Geode 1.10 after SD Moore reaches
GA.  Most likely, Spring Boot 2.3 will pull in SD Moore/2.3 and Spring Boot
2.3 will review all of it's "managed" [1] (fro instance [2]) dependencies
at that time.

The fact that Micrometer 1.0.3 was mention would mean that you are using
`spring-geode-starter` 1.0.x since Spring Boot has not be based on
Micrometer 1.0.x since 2.0 [3], which is now EOL.

-j

[1]
https://github.com/spring-projects/spring-boot/blob/v2.2.0.M6/spring-boot-project/spring-boot-dependencies/pom.xml#L34-L243
[2]
https://github.com/spring-projects/spring-boot/blob/v2.2.0.M6/spring-boot-project/spring-boot-dependencies/pom.xml#L153
[3]
https://github.com/spring-projects/spring-boot/blob/v2.0.9.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L127


On Wed, Sep 25, 2019 at 1:14 PM Jacob Barrett  wrote:

> Offline discovery…
>
> Looking at ./gradlew dependencies shows that micrometer is being
> downgraded by spring dependency plugin to 1.0.3. Attempting different
> versions of spring boot.
>
> -Jake
>
>
> > On Sep 25, 2019, at 1:04 PM, Owen Nichols  wrote:
> >
> > This still pulls in micrometer 1.0.3
> >
> > dependencies {
> >  compile('org.springframework.boot:spring-boot-starter')
> >
> >  implementation(platform('org.apache.geode:geode-client-bom:1.10.0'))
> >  implementation('org.apache.geode:geode-core')
> >  implementation('org.apache.geode:geode-cq')
> >
> >  testCompile('org.springframework.boot:spring-boot-starter-test')
> >  testCompile 'junit:junit:4.+'
> > }
> >
> >
> >> On Sep 25, 2019, at 12:43 PM, Jacob Barrett 
> wrote:
> >>
> >> Changing subject…
> >>
> >>
> >> Try
> >> dependencies {
> >>
> implementation(platform(‘org.apache.geode:geode-client-bom:1.10.0’))
> >>  implementation(‘org.apache.geode:geode-core’)
> >>  implementation('org.apache.geode:geode-cq’)
> >> }
> >>
> >> Does that make a difference?
> >>
> >>
> >>> On Sep 25, 2019, at 12:35 PM, Owen Nichols 
> wrote:
> >>>
> >>> My build.gradle is pretty simple:
> >>>
> >>> repositories {
> >>> mavenCentral()
> >>> maven {
> >>>  url '
> https://repository.apache.org/content/repositories/orgapachegeode-1059'
> >>> }
> >>> }
> >>>
> >>> dependencies {
> >>> compile('org.springframework.boot:spring-boot-starter')
> >>> compile 'org.apache.geode:geode-core:1.10.0'
> >>> compile 'org.apache.geode:geode-cq:1.10.0'
> >>> }
> >>>
> >>>
>  On Sep 25, 2019, at 12:29 PM, Jacob Barrett 
> wrote:
> 
> 
> 
> > On Sep 25, 2019, at 12:26 PM, Owen Nichols 
> wrote:
> >
> > ⚠️ to run my spring boot client for above test, I had to manually
> add compile 'io.micrometer:micrometer-c

Re: Spring Boot with Geode 1.10

[John Blum]

Additionally, I would encourage others to read...

https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#build-tool-plugins-maven-plugin

And, when using Gradle (instead)...

https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#build-tool-plugins-gradle-plugin

This section of Spring Boot's Maven/Gradle Plugin explains it best...

https://docs.spring.io/spring-boot/docs/2.1.7.RELEASE/gradle-plugin/reference/html/#managing-dependencies

-j


On Wed, Sep 25, 2019 at 1:24 PM John Blum  wrote:

> There is no version of Spring Boot (SBDG) currently built on Apache Geode
> 1.10 at the moment.
>
> In general, you should understand 2 things.
>
>
> 1. First, the Apache Geode version that Spring Boot, or SBDG, is dependent
> on is indirectly (transitively) determined by upstream dependencies.
>
> SBDG -> Spring Boot -> SDG -> Apache Geode.
>
> E.g. SDG Moore/2.2 pulls in Apache Geode 1.9.x.  SBDG 1.2 pulls in SDG
> Moore/2.2.  Spring Boot 2.2 also pulls in SD[G] Moore/2.2. Both SBDG and
> Spring Boot must agree on the version of SD[G] that they use.  So, it is
> not a coincidence that both SBDG (1.2) and Spring Boot (2.2) pull in SD
> Moore/2.2 and are therefore both (indirectly) dependent on Apache Geode 1.9.
>
> E.g. SDG Lovelace/2.1 pulls in Apache Geode 1.6.  SBDG 1.1 pulls in SDG
> Lovelace/2.1.  Spring Boot 2.1 also pulls in SD[G] Lovelace/2.2.  Both SBDG
> and Spring Boot must agree on the version of SD[G] that they use in 1.1/2.1
> respectively.
>
>
> 2. Next, Spring Boot's dependency management extends beyond simply Spring
> Data, to other (upstream, from Boot) Spring projects/dependencies (e.g.
> Spring Framework, Spring Batch, Spring Integration, Spring Security, etc)
> as well as 3rd party libraries.
>
>
> Any, and I mean ANY (!) properly managed Java project, not just Spring,
> must manage dependencies in a consistent and responsible way to avoid
> conflicts that would cause end users issues (especially with their
> applications that consume our dependencies) given multiple transitive
> dependencies are likely to share the same dependencies (e.g. logging is
> always usually the most common example).
>
> You should not assume you can just simply change dependencies at random
> (e.g. I will use Spring Boot 2.2 with SBDG 1.1, or change the Micrometer
> versions, or whatever).  The stars must align so to speak, and for good
> reason.  Again, this is why tools like Apache Maven exists in the first
> place.
>
> In some cases, this might work, but it is not normal to think you can do
> this in general, and most of the Java community understands this.  It must
> be a conscious choice and users are aware that they must manually
> exclude/override a dependency and/or declare their own dependencyManagement
> section in their application POM to declare their choices.
>
> Anyway, this 1 of the many reasons why Spring Boot so eloquently handles
> this concern for you.
>
> SDG Neuman/2.3 will be based on Apache Geode 1.10 after SD Moore reaches
> GA.  Most likely, Spring Boot 2.3 will pull in SD Moore/2.3 and Spring Boot
> 2.3 will review all of it's "managed" [1] (fro instance [2]) dependencies
> at that time.
>
> The fact that Micrometer 1.0.3 was mention would mean that you are using
> `spring-geode-starter` 1.0.x since Spring Boot has not be based on
> Micrometer 1.0.x since 2.0 [3], which is now EOL.
>
> -j
>
> [1]
> https://github.com/spring-projects/spring-boot/blob/v2.2.0.M6/spring-boot-project/spring-boot-dependencies/pom.xml#L34-L243
> [2]
> https://github.com/spring-projects/spring-boot/blob/v2.2.0.M6/spring-boot-project/spring-boot-dependencies/pom.xml#L153
> [3]
> https://github.com/spring-projects/spring-boot/blob/v2.0.9.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L127
>
>
> On Wed, Sep 25, 2019 at 1:14 PM Jacob Barrett  wrote:
>
>> Offline discovery…
>>
>> Looking at ./gradlew dependencies shows that micrometer is being
>> downgraded by spring dependency plugin to 1.0.3. Attempting different
>> versions of spring boot.
>>
>> -Jake
>>
>>
>> > On Sep 25, 2019, at 1:04 PM, Owen Nichols  wrote:
>> >
>> > This still pulls in micrometer 1.0.3
>> >
>> > dependencies {
>> >  compile('org.springframework.boot:spring-boot-starter')
>> >
>> >  implementation(platform('org.apache.geode:geode-client-bom:1.10.0'))
>> >  implementation('org.apache.geode:geode-core')
>> >  implementation('org.apache.geode:geode-cq')
>> >
>> >  testCompile('org.springframework.boot:spring-boot-starter-test')
>> >  testCompile 'junit:junit:4.+'
>> > }
>> >
>> >
>> >> On Sep 25, 2019, at 12:43 PM, Jacob Barrett 
>> wrote:
>> >>
>> >> Changing subject…
>> >>
>> >>
>> >> Try
>> >> dependencies {
>> >>
>> implementation(platform(‘org.apache.geode:geode-client-bom:1.10.0’))
>> >>  implementation(‘org.apache.geode:geode-core’)
>> >>  implementation('org.apache.geode:geode-cq’)
>> >> }
>> >>
>> >> Does that make a difference?
>> >>
>> >>
>> >>> On Sep 25, 2019, at 12:35 PM, Owen Nichols 

Re: Spring Boot with Geode 1.10

[Owen Nichols]

That was the problem ... I had an old reference to Spring Boot v2.0.1.  Updated 
it to 2.1.9 and now the micrometer versions line up.  But I appreciate your 
broader point: even that version of Spring Boot is only intended to work with 
Geode 1.9, so trying to mix-and-match with 1.10 is ill-advised at best.  Maybe 
for the purpose of validating Geode release candidates, the best thing for me 
would be to un-boot-ify my client app.

Thanks everyone for helping me figure out my dependency management puzzle. 

-Owen


> On Sep 25, 2019, at 1:24 PM, John Blum  wrote:
> 
> There is no version of Spring Boot (SBDG) currently built on Apache Geode
> 1.10 at the moment.
> 
> In general, you should understand 2 things.
> 
> 
> 1. First, the Apache Geode version that Spring Boot, or SBDG, is dependent
> on is indirectly (transitively) determined by upstream dependencies.
> 
> SBDG -> Spring Boot -> SDG -> Apache Geode.
> 
> E.g. SDG Moore/2.2 pulls in Apache Geode 1.9.x.  SBDG 1.2 pulls in SDG
> Moore/2.2.  Spring Boot 2.2 also pulls in SD[G] Moore/2.2. Both SBDG and
> Spring Boot must agree on the version of SD[G] that they use.  So, it is
> not a coincidence that both SBDG (1.2) and Spring Boot (2.2) pull in SD
> Moore/2.2 and are therefore both (indirectly) dependent on Apache Geode 1.9.
> 
> E.g. SDG Lovelace/2.1 pulls in Apache Geode 1.6.  SBDG 1.1 pulls in SDG
> Lovelace/2.1.  Spring Boot 2.1 also pulls in SD[G] Lovelace/2.2.  Both SBDG
> and Spring Boot must agree on the version of SD[G] that they use in 1.1/2.1
> respectively.
> 
> 
> 2. Next, Spring Boot's dependency management extends beyond simply Spring
> Data, to other (upstream, from Boot) Spring projects/dependencies (e.g.
> Spring Framework, Spring Batch, Spring Integration, Spring Security, etc)
> as well as 3rd party libraries.
> 
> 
> Any, and I mean ANY (!) properly managed Java project, not just Spring,
> must manage dependencies in a consistent and responsible way to avoid
> conflicts that would cause end users issues (especially with their
> applications that consume our dependencies) given multiple transitive
> dependencies are likely to share the same dependencies (e.g. logging is
> always usually the most common example).
> 
> You should not assume you can just simply change dependencies at random
> (e.g. I will use Spring Boot 2.2 with SBDG 1.1, or change the Micrometer
> versions, or whatever).  The stars must align so to speak, and for good
> reason.  Again, this is why tools like Apache Maven exists in the first
> place.
> 
> In some cases, this might work, but it is not normal to think you can do
> this in general, and most of the Java community understands this.  It must
> be a conscious choice and users are aware that they must manually
> exclude/override a dependency and/or declare their own dependencyManagement
> section in their application POM to declare their choices.
> 
> Anyway, this 1 of the many reasons why Spring Boot so eloquently handles
> this concern for you.
> 
> SDG Neuman/2.3 will be based on Apache Geode 1.10 after SD Moore reaches
> GA.  Most likely, Spring Boot 2.3 will pull in SD Moore/2.3 and Spring Boot
> 2.3 will review all of it's "managed" [1] (fro instance [2]) dependencies
> at that time.
> 
> The fact that Micrometer 1.0.3 was mention would mean that you are using
> `spring-geode-starter` 1.0.x since Spring Boot has not be based on
> Micrometer 1.0.x since 2.0 [3], which is now EOL.
> 
> -j
> 
> [1]
> https://github.com/spring-projects/spring-boot/blob/v2.2.0.M6/spring-boot-project/spring-boot-dependencies/pom.xml#L34-L243
> [2]
> https://github.com/spring-projects/spring-boot/blob/v2.2.0.M6/spring-boot-project/spring-boot-dependencies/pom.xml#L153
> [3]
> https://github.com/spring-projects/spring-boot/blob/v2.0.9.RELEASE/spring-boot-project/spring-boot-dependencies/pom.xml#L127
> 
> 
> On Wed, Sep 25, 2019 at 1:14 PM Jacob Barrett  wrote:
> 
>> Offline discovery…
>> 
>> Looking at ./gradlew dependencies shows that micrometer is being
>> downgraded by spring dependency plugin to 1.0.3. Attempting different
>> versions of spring boot.
>> 
>> -Jake
>> 
>> 
>>> On Sep 25, 2019, at 1:04 PM, Owen Nichols  wrote:
>>> 
>>> This still pulls in micrometer 1.0.3
>>> 
>>> dependencies {
>>> compile('org.springframework.boot:spring-boot-starter')
>>> 
>>> implementation(platform('org.apache.geode:geode-client-bom:1.10.0'))
>>> implementation('org.apache.geode:geode-core')
>>> implementation('org.apache.geode:geode-cq')
>>> 
>>> testCompile('org.springframework.boot:spring-boot-starter-test')
>>> testCompile 'junit:junit:4.+'
>>> }
>>> 
>>> 
 On Sep 25, 2019, at 12:43 PM, Jacob Barrett 
>> wrote:
 
 Changing subject…
 
 
 Try
 dependencies {
 
>> implementation(platform(‘org.apache.geode:geode-client-bom:1.10.0’))
 implementation(‘org.apache.geode:geode-core’)
 implementation('org.apache.geode:geode-cq’)
 }
 
 Does that make a difference?
 
 
> On

[VOTE] Apache Geode 1.10.0.RC2

[Dick Cavender]

It's past the announced deadline and we have enough votes to close the
voting.

Voting status
==
+1: 7 binding votes, 2 non-binding votes
* Dave Barnes (PMC member)
* Anthony Baker (PMC Member)
* Jinmei Liao (PMC member)
* Jacob Barrett  (PMC member)
* Dan Smith (PMC member)
* Udo Kohlmeyer (PMC member)
* Kirk Lund (PMC member)
* Owen Nichols (Non-binding)
* Aaron Lindsey (Non-binding)

+0: zero votes

-0: zero votes

-1: zero votes

The voting meets the requirements of at least 3 PMC members with +1 votes and
has the required majority of +1 votes.

Apache Geode 1.10.0 passes the vote so I will finalize the release shortly.

Thanks everyone for the great work!

Dick Cavender

Re: [PROPOSAL] adding java-jq to GEODE dependency for testing

[Kirk Lund]

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  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  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 
> 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  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 
> wrote:
> >>>
>  Sounds good, thanks for the heads up.
> 
>  Anthony
> 
> 
> > On Sep 25, 2019, at 8:37 AM, Jinmei Liao  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
>
>

Re: [PROPOSAL] adding java-jq to GEODE dependency for testing

[Udo Kohlmeyer]

I don't know enough about the limitations between the two libraries. BUT

I would prefer, like Kirk, some consistency w.r.t. implementations. 
Also, this is for testing, so I'm really questioning are we going to be 
pushing the boundaries of what this library can do. In addition, if 
there would be some extra steps that we might have to do, to confirm the 
validity of the returned JSON, compared to the native jq implementation, 
so be it.


But, maybe the other question we have not yet answered is, what is the 
our perception on the lifetime of this implementation. IF we go with the 
pure java implementation AND we are so tightly bound to it and they stop 
development on it, then we have a whole team of java devs that can take 
it over and fix/improve. In the native implementation, this is less 
true, so it really becomes a question about, can we maintain it if 
necessary.


--Udo

On 9/25/19 4:20 PM, Kirk Lund wrote:

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  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  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 

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  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 

wrote:

Sounds good, thanks for the heads up.

Anthony



On Sep 25, 2019, at 8:37 AM, Jinmei Liao  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

Errored: apache/geode-examples#366 (rel/v1.10.0 - 075158b)

[Travis CI]

Build Update for apache/geode-examples
-

Build: #366
Status: Errored

Duration: 53 secs
Commit: 075158b (rel/v1.10.0)
Author: Dick Cavender
Message: temporarily point to staging repo for CI purposes

View the changeset: https://github.com/apache/geode-examples/compare/rel/v1.10.0

View the full build log and details: 
https://travis-ci.org/apache/geode-examples/builds/589698147?utm_medium=notification&utm_source=email

--

You can unsubscribe from build emails from the apache/geode-examples repository 
going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=11483039&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

Passed: apache/geode-native#2119 (rel/v1.10.0 - 0668f6b)

[Travis CI]

Build Update for apache/geode-native
-

Build: #2119
Status: Passed

Duration: 1 hr, 34 mins, and 37 secs
Commit: 0668f6b (rel/v1.10.0)
Author: Owen Nichols
Message: GEODE-7182: fix a warning in TcpSslConn.cpp that prevents successful 
compilation on gcc 8.3 (#515)


(cherry picked from commit 9b1c5ab31558c9d0ead6927398cb608521a5c20d)

View the changeset: https://github.com/apache/geode-native/compare/rel/v1.10.0

View the full build log and details: 
https://travis-ci.org/apache/geode-native/builds/589698172?utm_medium=notification&utm_source=email

--

You can unsubscribe from build emails from the apache/geode-native repository 
going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=11948127&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.