RE: [DISCUSS] Bug while parsing the JSON "key which having short data type" in locate command "https://github.com/apache/geode/pull/752"

[Dinesh Akhand]

Hi Team,

I fixed the first review code comments. Please review again.

Thanks,
Dinesh Akhand

-Original Message-
From: dinesh 1004 [mailto:dineshpune2...@gmail.com] 
Sent: Wednesday, September 6, 2017 10:23 PM
To: dev@geode.apache.org
Subject: RE: [DISCUSS] Bug while parsing the JSON "key which having short data 
type" in locate command "https://github.com/apache/geode/pull/752;

Need suggestions on same pull request

Thanks,
Dinesh

On 1 Sep 2017 09:46, "Dinesh Akhand"  wrote:

> Hi Team,
>
> Please reply over below mail chain.
>
> Need you focus on the issue.
>
> Thanks,
> Dinesh Akhand
>
> -Original Message-
> From: Dinesh Akhand
> Sent: Thursday, August 31, 2017 7:04 PM
> To: dev@geode.apache.org
> Subject: [DISCUSS] Bug while parsing the JSON "key which having short 
> data type" in locate command "https://github.com/apache/geode/pull/752;
>
> Hi,
>
>
>
> I have created the pull request for the same .
>
> https://github.com/apache/geode/pull/752
>
>
>
> Jira ticket GEODE-3544.
>
>
>
> Case 1)
>
>
>
> Short data type is getting converted into integer &  geode is looking 
> for set method  with integer
>
> And it throws the exception.
>
>
>
> So I am converting the value with parameterType  using 
> ConvertUtils.convert which solve the problem for all primitive/wrapper 
> type
>
> Example 2)
>
>  If key data type in short i =5
>
>   It will look for method  seti(integer )
>
> Case 2) If key having the base class it check only key class set method .
>
>
>
> So I change getDeclaredMethods to getMethods()
>
>
>
>
>
> Thanks,
>
> Dinesh Akhand
>
>
>
> -Original Message-
> From: Dinesh Akhand
> Sent: Monday, August 28, 2017 5:46 PM
> To: dev@geode.apache.org
> Subject: Bug while parsing the JSON "key which having short data type" 
> in locate command
>
>
>
> Hi Team,
>
>
>
> I have found one bug in geode 1.2 .
>
>
>
> If in the key we having the short data type
>
>
>
> Example:
>
>
>
> public class EmpData  implements Serializable{ private short empid;
>
>
>
> public short getEmpid() {
>
>return empid;
>
> }
>
>
>
> public void setEmpid(short empid) {
>
>this.empid = empid;
>
> }
>
>
>
>
>
> EmpData d1 = new EmpData();
>
> D1. setEmpid((short)1);
>
>
>
> Region.put(d1,"value1");
>
>
>
> Now try locate command on this .
>
>
>
>
>
> Problem in code: file JSONTokener.java. it always return short to int 
> value
>
>
>
> try {
>
> long longValue = Long.parseLong(number, base);
>
> if(longValue <= Short.MAX_VALUE && longValue >= 
> Short.MIN_VALUE)
>
> {
>
>  return (short) longValue;
>
> }
>
> else if (longValue <= Integer.MAX_VALUE && longValue >=
> Integer.MIN_VALUE) {
>
>   return (int) longValue;
>
> } else {
>
>   return longValue;
>
> }
>
>
>
> Later it cause the problem of java.lang.IllegalArgumentException:
> argument type mismatch.
>
> locate entry --key=--key=('empid ':1) --region=CUSTOMER_1
>
>
>
> alternate way :  changes the  DataCommandFunctionJUnitTest.java 
> changes the testLocateKeyIsObject method
>
>
>
> due to same problem, we are facing problem with all commands where we 
> usage the key.
>
>
>
> Thanks,
>
> Dinesh Akhand
>
>
>
>
>
> This message and the information contained herein is proprietary and 
> confidential and subject to the Amdocs policy statement,
>
>
>
> you may review at https://www.amdocs.com/about/email-disclaimer < 
> https://www.amdocs.com/about/email-disclaimer>
> This message and the information contained herein is proprietary and 
> confidential and subject to the Amdocs policy statement,
>
> you may review at https://www.amdocs.com/about/email-disclaimer < 
> https://www.amdocs.com/about/email-disclaimer>
> This message and the information contained herein is proprietary and 
> confidential and subject to the Amdocs policy statement,
>
> you may review at https://www.amdocs.com/about/email-disclaimer < 
> https://www.amdocs.com/about/email-disclaimer>
>
>
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

Re: 1.3.0 release

[Swapnil Bawaskar]

Sound good.

I would like to volunteer to be the release manager.

Thanks!


On Tue, Sep 12, 2017 at 2:24 PM Anthony Baker  wrote:

> Hi all,
>
> I think we should begin discussing scope and timeline for the 1.3.0
> release.  I know we’re still finalizing 1.2.1, but we released 1.2.0 almost
> two months ago and we’ve fixed almost 200 issues in that time.  IMO, we
> should complete 1.2.1 and then immediately turn around 1.3.0.
>
> Thoughts?  Any volunteers for release manager?
>
> Anthony
>
>

1.3.0 release

[Anthony Baker]

Hi all,

I think we should begin discussing scope and timeline for the 1.3.0 release.  I 
know we’re still finalizing 1.2.1, but we released 1.2.0 almost two months ago 
and we’ve fixed almost 200 issues in that time.  IMO, we should complete 1.2.1 
and then immediately turn around 1.3.0.

Thoughts?  Any volunteers for release manager?

Anthony

Re: How to setup 2-phase auth for Github

[Kirk Lund]

Thanks Dave! I have the Github 2-phase auth working with GA now.

Here's the URL in case anyone else ends up looking for it...

https://help.github.com/articles/configuring-two-factor-authentication-via-a-totp-mobile-app/

Thanks,
Kirk

On Tue, Sep 12, 2017 at 11:06 AM, Dave Barnes  wrote:

> It's kind of buried under the "TOTP Mobile App" heading. You connect Google
> Authenticator to Github when you shoot a photo of the code square.
>
> On Tue, Sep 12, 2017 at 10:58 AM, Kirk Lund  wrote:
>
> > I'm trying to get setup for gitbox, but a couple details are not panning
> > out correctly for me. Darrel is using Google Authenticator on iphone for
> > 2-phase auth of Github. However, the URL that gives directions for
> setting
> > up 2-phase auth of Github does NOT have a section for setting up Google
> > Authenticator for Github on iphone:
> > https://help.github.com/articles/securing-your-account-with-two-factor-
> > authentication-2fa/
> >
> > Can anyone tell me how to setup 2-phase auth of Github using Google
> > Authenticator on iphone?
> >
> > Thanks,
> > Kirk
> >
>

Re: [Discuss] Investigation of C++ object return types

[Jacob Barrett]

My biggest concern with this model is that access to the public Cache
object from other public objects results in additional allocations of a
Cache value. Think about when we are inside a Serializable object and we
access the Cache from DataOutput.

As value:
Serializable* MyClass::fromData(DataInput& dataInput) {
  auto cache = dataOutput.getCache();
  ...
}
In this the value of cache will RVO the allocation of Cache in the getCache
call into the stack of this method, great. The problem is that Cache must
contain a std::shared_ptr which means that each allocation is 8
bytes (pointer to control block and pointer to CacheImpl) as well as having
to increment the strong counter in the control block. On exit/descope, the
Cache will have to decrement the control block as well.

Using current shared_ptr pimple model:
Serializable* MyClass::fromData(DataInput& dataInput) {
  auto& cache = dataOutput.getCache();
  ...
}
We only suffer the ref allocation of 4 bytes and no ref count. Since this
function call can't survive past the lifespan of Cache/CacheImpl they don't
need to have shared_ptr and refcounting.

Given that this method could be called numerous times is the overhead of
the value version going to be a significant performance issue?

I worry that moves and RVO is just beyond most developers. Heck I didn't
know anything about it until we started exploring it.



-Jake


On Tue, Sep 12, 2017 at 8:06 AM David Kimura  wrote:

> Follow up of attached discussion after more investigation.  I created an
> example of returning Cache as shared pointer versus raw value:
>
> https://github.com/dgkimura/geode-native-sandbox
>
> I still like returning by value as it lets the user do what they want with
> their object.
>
> // Here user creates object on their stack.
> auto c = CacheFactory::createFactory().create();
>
> // Here user creates smart pointer in their heap.
> auto cptr =
> std::make_shared(CacheFactory::createFactory().create());
>
> Difficulty of implementing this is high due to circular dependencies of
> Cache/CacheImpl as well as objects hanging off CacheImpl that return
> Cache.  We must be extra careful when dealing with move/copy semantics of
> Cache/CacheImpl.
>
> Alternative, is to keep as is and only permit heap allocations from
> factory using shared pointers.
>
> Thanks,
> David
>

Re: How to setup 2-phase auth for Github

[Dave Barnes]

It's kind of buried under the "TOTP Mobile App" heading. You connect Google
Authenticator to Github when you shoot a photo of the code square.

On Tue, Sep 12, 2017 at 10:58 AM, Kirk Lund  wrote:

> I'm trying to get setup for gitbox, but a couple details are not panning
> out correctly for me. Darrel is using Google Authenticator on iphone for
> 2-phase auth of Github. However, the URL that gives directions for setting
> up 2-phase auth of Github does NOT have a section for setting up Google
> Authenticator for Github on iphone:
> https://help.github.com/articles/securing-your-account-with-two-factor-
> authentication-2fa/
>
> Can anyone tell me how to setup 2-phase auth of Github using Google
> Authenticator on iphone?
>
> Thanks,
> Kirk
>

How to setup 2-phase auth for Github

[Kirk Lund]

I'm trying to get setup for gitbox, but a couple details are not panning
out correctly for me. Darrel is using Google Authenticator on iphone for
2-phase auth of Github. However, the URL that gives directions for setting
up 2-phase auth of Github does NOT have a section for setting up Google
Authenticator for Github on iphone:
https://help.github.com/articles/securing-your-account-with-two-factor-authentication-2fa/

Can anyone tell me how to setup 2-phase auth of Github using Google
Authenticator on iphone?

Thanks,
Kirk

Re: [Discuss] Building objects with the Factory pattern or the Builder pattern. Adding the fluent model?

[Kirk Lund]

I don't think we currently have any design directions or architectural
rules for Geode documented yet other than for GFSH. As we refactor code, we
really should be following some sort of overall design guidelines.

+1 for documenting (on the wiki) and promoting fluent style APIs in our
design guidelines going forward

On Wed, Sep 6, 2017 at 5:19 PM, Mark Hanson  wrote:

> For me there is only one real challenge, not an objection as I like builder
> and fluent models as well, but there is an added challenge of debugging. it
> can effectively combine 5 lines into one, which means it is *slightly* more
> annoying to debug, and the fact that return values go away, but for a
> builder object, that shouldn't be an issue.
>
> I think moving the C++ API there in the short term is a point for
> discussion, but I like the direction.
>
> On Wed, Sep 6, 2017 at 1:56 PM, Ernest Burghardt 
> wrote:
>
> > I really like the Fluent pattern as it is done in C# and Java...
> >
> > I'm not sure the juice is worth the squeeze in an existing c++ library.
> >
> > I do agree we should normalize our factory/builder patterns.
> >
> > On Wed, Sep 6, 2017 at 12:28 PM, Jacob Barrett 
> > wrote:
> >
> > > Mark,
> > >
> > > I believe the real issue is that we use multiple patterns and should be
> > > converging on one pattern. We have examples of both Factory and Builder
> > > models and both with and without Fluent pattern.
> > >
> > > If the Java API is tending towards Builder model with Fluent pattern
> > then I
> > > am for that as long as this common practice in the C++ world. In my
> > > searching I don't see any strong tendency towards any one model or
> > pattern
> > > in the C++ world. The only real trick to the Fluent pattern in C++ is
> > what
> > > is the type of the return value? Is it &, *, or some smart pointer? I
> > would
> > > expect it be a ref. My only issue with this is that if the original
> > factory
> > > variable is a pointer then the operator changes, for example:
> > > prtToCachFactory->setSomething("arrow").setSomethingElse("dot");
> > >
> > > It also needs to be VERY clear in the docs is the builder could ever
> > return
> > > something other than a reference to the original instance of the
> > builder. I
> > > have seen models where it is possible so you have to do things like to
> > > guard against the return changing:
> > > auto cacheFactory = CacheFactory().setSomething().setSomethingElse();
> > > if (somethingMore) {
> > >   cacheFactory = cacheFactory.setSomethingMore();
> > > }
> > > auto cache = cacheFactory.create();
> > >
> > > If you have to do that then it because less desirable to have the
> fluent
> > > pattern because it is prone to error and less readable. We should
> > guarantee
> > > something like this will work:
> > > auto cacheFactory = CacheFactory().setSomething().setSomethingElse();
> > > if (somethingMore) {
> > >   cacheFactory.setSomethingMore();
> > > }
> > > auto cache = cacheFactory.create();
> > >
> > > -Jake
> > >
> > >
> > >
> > >
> > > On Wed, Sep 6, 2017 at 10:38 AM Darrel Schneider <
> dschnei...@pivotal.io>
> > > wrote:
> > >
> > > > In the geode java apis you would create a CacheFactory (or
> > > > ClientCacheFactory), configure it fluently, and then call create at
> the
> > > > end. So even though we call them factories in the geode java apis,
> they
> > > use
> > > > the Builder pattern and also support the fluent model in that you
> could
> > > do
> > > > this:
> > > >   ClientCache cache = new  ClientCacheFactory().set("propName",
> > > > "propValue").addPoolLocator("addr", 10678).create();
> > > >
> > > >  Also in java the DistributedSystem is hidden under the Cache. So you
> > add
> > > > config to your CacheFactory and when you create it, it will also
> > connect
> > > > the DistributedSystem. It used to be that in java you had to connect
> > the
> > > > DistributedSystem first and then the Cache. Since the
> DistributedSystem
> > > is
> > > > never used apart for a Cache I think this simplification was helpful
> to
> > > > users.
> > > >
> > > > On Wed, Sep 6, 2017 at 10:13 AM, Mark Hanson 
> > wrote:
> > > >
> > > > > Problem:
> > > > >
> > > > > To fluent and builder model or not to fluent and builder model
> In
> > > the
> > > > > native client
> > > > >
> > > > > we use the factory model of generating objects, we are wondering
> if a
> > > > move
> > > > > to the fluent model
> > > > >
> > > > > and the builder pattern would be better.
> > > > >
> > > > >
> > > > > Background:
> > > > >
> > > > > In designing the various types of allocators for our objects, we
> have
> > > > > considered
> > > > >
> > > > > whether or not use the builder and fluent patterns instead of the
> > > Factory
> > > > > pattern.
> > > > >
> > > > > The current code base is written following the factory pattern, but
> > it
> > > > > seems that
> > > > >
> > > > > the Builder pattern is becoming 

Re: [DISCUSS] Clean build takes 10minutes to complete now

[Udo Kohlmeyer]

My apologies, I might gotten the commit reason incorrect. I just know that
downloading the older product version every time is becoming painful.
Yes, sometimes it is faster than other times, but imo, this is not
something that should be part of the main build path.

Backwards compat or integration testing should not be running as part of
the main build task.

--Udo

On Tue, Sep 12, 2017 at 9:05 AM, Nabarun Nag  wrote:

> As we are working on fixing this issue, some extra parameters may help the
> build to get bit quicker on your machine.
>
> using -xjavadoc -xdoc
> Eg: ./gradlew clean build -Dskip.tests=true -xjavadoc -xdocs
> BUILD SUCCESSFUL
> Total time: 2 mins 2.729 secs
>
>
> Also, I think as Jason mentioned that the slow down is due to full product
> download for session state tests. LuceneSearchWithRollingUpgradeDUnit
> tests
> were added  in July. Please do correct me if I am wrong.
>
> Regards
> Nabarun
>
>
> On Tue, Sep 12, 2017 at 11:47 AM Alexander Murmann 
> wrote:
>
> > Could we make it so that these tests for now are only run as part of
> > pre-checkin till we got this ironed out and then revisit this?
> >
> > On Tue, Sep 12, 2017 at 8:32 AM, Bruce Schuchardt <
> bschucha...@pivotal.io>
> > wrote:
> >
> > > The geode-old-versions module was originally created to pull in old
> > > version jar files into your gradle cache.  This happened only once and
> > you
> > > were good to go.  I don't think that part should be backed out as it
> has
> > > minimal impact and is not affecting build time.
> > >
> > > The recent changes for lucene testing seem to be pulling in full
> > > installations of old versions and these are deleted as part of the
> > "clean"
> > > gradle task.  That's causing them to be downloaded again each time you
> > do a
> > > clean  Dan put changes in place so that the files aren't
> > downloaded
> > > again if you build without cleaning but clearly more needs to be done
> in
> > > this area.
> > >
> > >
> > >
> > > On 9/11/17 11:23 AM, Jacob Barrett wrote:
> > >
> > >> Agreed, integration tests should not be part of the build process.
> This
> > >> is clearly an integration test.
> > >>
> > >> On Sep 11, 2017, at 11:00 AM, Udo Kohlmeyer  wrote:
> > >>>
> > >>> Hi there,
> > >>>
> > >>> With a recent addition to the build scripts, to test lucene backwards
> > >>> compatibility, a step was added to download a previous version of
> > GEODE.
> > >>>
> > >>> This is causing longer build times now, which is a real distraction.
> In
> > >>> cases where one would like to work on a branch, rebase that on
> develop
> > and
> > >>> merge that, this step becomes a real time hog.
> > >>>
> > >>> I request that we remove this default behavior from a clean build
> until
> > >>> we have a better solution to this issue.
> > >>>
> > >>> I also believe that if anyone wants to add behavior like this into
> the
> > >>> default build, that it at least is discussed on the dev list before
> > >>> implementing this.
> > >>>
> > >>> --Udo
> > >>>
> > >>>
> > >
> >
>



-- 
Kindest Regards
-
*Udo Kohlmeyer* | *Snr Solutions Architect* |*Pivotal*
*Mobile:* +61 409-279-160 | ukohlme...@pivotal.io

www.pivotal.io

Re: [DISCUSS] Clean build takes 10minutes to complete now

[Nabarun Nag]

As we are working on fixing this issue, some extra parameters may help the
build to get bit quicker on your machine.

using -xjavadoc -xdoc
Eg: ./gradlew clean build -Dskip.tests=true -xjavadoc -xdocs
BUILD SUCCESSFUL
Total time: 2 mins 2.729 secs


Also, I think as Jason mentioned that the slow down is due to full product
download for session state tests. LuceneSearchWithRollingUpgradeDUnit tests
were added  in July. Please do correct me if I am wrong.

Regards
Nabarun


On Tue, Sep 12, 2017 at 11:47 AM Alexander Murmann 
wrote:

> Could we make it so that these tests for now are only run as part of
> pre-checkin till we got this ironed out and then revisit this?
>
> On Tue, Sep 12, 2017 at 8:32 AM, Bruce Schuchardt 
> wrote:
>
> > The geode-old-versions module was originally created to pull in old
> > version jar files into your gradle cache.  This happened only once and
> you
> > were good to go.  I don't think that part should be backed out as it has
> > minimal impact and is not affecting build time.
> >
> > The recent changes for lucene testing seem to be pulling in full
> > installations of old versions and these are deleted as part of the
> "clean"
> > gradle task.  That's causing them to be downloaded again each time you
> do a
> > clean  Dan put changes in place so that the files aren't
> downloaded
> > again if you build without cleaning but clearly more needs to be done in
> > this area.
> >
> >
> >
> > On 9/11/17 11:23 AM, Jacob Barrett wrote:
> >
> >> Agreed, integration tests should not be part of the build process. This
> >> is clearly an integration test.
> >>
> >> On Sep 11, 2017, at 11:00 AM, Udo Kohlmeyer  wrote:
> >>>
> >>> Hi there,
> >>>
> >>> With a recent addition to the build scripts, to test lucene backwards
> >>> compatibility, a step was added to download a previous version of
> GEODE.
> >>>
> >>> This is causing longer build times now, which is a real distraction. In
> >>> cases where one would like to work on a branch, rebase that on develop
> and
> >>> merge that, this step becomes a real time hog.
> >>>
> >>> I request that we remove this default behavior from a clean build until
> >>> we have a better solution to this issue.
> >>>
> >>> I also believe that if anyone wants to add behavior like this into the
> >>> default build, that it at least is discussed on the dev list before
> >>> implementing this.
> >>>
> >>> --Udo
> >>>
> >>>
> >
>

Build failed in Jenkins: Geode-nightly-flaky #121

[Apache Jenkins Server]

See 


Changes:

[jdeppe] GEODE-3586: Fix syntax in uploadArchives task (since gradle 3.5)

[dcavender] GEODE-3587: Enable publishing distribution zip

[jiliao] GEODE-2817: consolidate authorize(*) methods

[jiliao] GEODE-3096: pulling in refactoring work on HttpOperationInvoker

[dschneider] GEODE-3543: refactor ExpiryTask to not call 
GemFireCacheImpl.getInstance

--
[...truncated 118.27 KB...]
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger-ui/2.6.1/springfox-swagger-ui-2.6.1.jar
Download 
https://repo1.maven.org/maven2/org/springframework/hateoas/spring-hateoas/0.23.0.RELEASE/spring-hateoas-0.23.0.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/scala-lang/scala-reflect/2.10.6/scala-reflect-2.10.6.jar
Download 
https://repo1.maven.org/maven2/com/fasterxml/jackson/module/jackson-module-paranamer/2.8.6/jackson-module-paranamer-2.8.6.jar
Download 
https://repo1.maven.org/maven2/io/swagger/swagger-annotations/1.5.10/swagger-annotations-1.5.10.jar
Download 
https://repo1.maven.org/maven2/io/swagger/swagger-models/1.5.10/swagger-models-1.5.10.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-spi/2.6.1/springfox-spi-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-schema/2.6.1/springfox-schema-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger-common/2.6.1/springfox-swagger-common-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-spring-web/2.6.1/springfox-spring-web-2.6.1.jar
Download 
https://repo1.maven.org/maven2/com/fasterxml/classmate/1.3.1/classmate-1.3.1.jar
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-core/1.2.0.RELEASE/spring-plugin-core-1.2.0.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-metadata/1.2.0.RELEASE/spring-plugin-metadata-1.2.0.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/mapstruct/mapstruct/1.0.0.Final/mapstruct-1.0.0.Final.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-core/2.6.1/springfox-core-2.6.1.jar
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:geode-web-api:processResources
:geode-web-api:classes
:geode-assembly:docs:101:
 warning - Tag @link: reference not found: BasicTypes.Entry

1 warning
:geode-assembly:gfshDepsJar
:geode-common:javadocJar
:geode-common:sourcesJar
:geode-common:signArchives SKIPPED
:geode-core:javadocJar
:geode-core:raJar
:geode-core:jcaJar
:geode-core:sourcesJar
:geode-core:signArchives SKIPPED
:geode-core:webJar
:geode-cq:jar
:geode-cq:javadoc
:geode-cq:javadocJar
:geode-cq:sourcesJar
:geode-cq:signArchives SKIPPED
:geode-json:javadocJar
:geode-json:sourcesJar
:geode-json:signArchives SKIPPED
:geode-lucene:jar
:geode-lucene:javadoc
:geode-lucene:javadocJar
:geode-lucene:sourcesJar
:geode-lucene:signArchives SKIPPED
:geode-old-client-support:jar
:geode-old-client-support:javadoc
:geode-old-client-support:javadocJar
:geode-old-client-support:sourcesJar
:geode-old-client-support:signArchives SKIPPED
:geode-protobuf:jar
:geode-protobuf:javadoc:101:
 warning - Tag @link: reference not found: BasicTypes.Entry

1 warning
:geode-protobuf:javadocJar
:geode-protobuf:sourcesJar
:geode-protobuf:signArchives SKIPPED
:geode-pulse:javadoc
:geode-pulse:javadocJar
:geode-pulse:sourcesJar
:geode-pulse:war
:geode-pulse:signArchives SKIPPED
:geode-rebalancer:jar
:geode-rebalancer:javadoc
:geode-rebalancer:javadocJar
:geode-rebalancer:sourcesJar
:geode-rebalancer:signArchives SKIPPED
:geode-wan:jar
:geode-wan:javadoc
:geode-wan:javadocJar
:geode-wan:sourcesJar
:geode-wan:signArchives SKIPPED
:geode-web:javadoc NO-SOURCE
:geode-web:javadocJar
:geode-web:sourcesJar
:geode-web:war
:geode-web:signArchives SKIPPED
:geode-web-api:javadoc
:geode-web-api:javadocJar
:geode-web-api:sourcesJar
:geode-web-api:war
:geode-web-api:signArchives SKIPPED
:geode-assembly:installDist
:geode-pulse:jar
:geode-assembly:compileTestJava
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core-uberjar/1.6.3/cargo-core-uberjar-1.6.3.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core/1.6.3/cargo-core-1.6.3.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/codehaus-cargo/1.6.3/codehaus-cargo-1.6.3.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core-uberjar/1.6.3/cargo-core-uberjar-1.6.3.jar
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: 

Re: [DISCUSS] Clean build takes 10minutes to complete now

[Alexander Murmann]

Could we make it so that these tests for now are only run as part of
pre-checkin till we got this ironed out and then revisit this?

On Tue, Sep 12, 2017 at 8:32 AM, Bruce Schuchardt 
wrote:

> The geode-old-versions module was originally created to pull in old
> version jar files into your gradle cache.  This happened only once and you
> were good to go.  I don't think that part should be backed out as it has
> minimal impact and is not affecting build time.
>
> The recent changes for lucene testing seem to be pulling in full
> installations of old versions and these are deleted as part of the "clean"
> gradle task.  That's causing them to be downloaded again each time you do a
> clean  Dan put changes in place so that the files aren't downloaded
> again if you build without cleaning but clearly more needs to be done in
> this area.
>
>
>
> On 9/11/17 11:23 AM, Jacob Barrett wrote:
>
>> Agreed, integration tests should not be part of the build process. This
>> is clearly an integration test.
>>
>> On Sep 11, 2017, at 11:00 AM, Udo Kohlmeyer  wrote:
>>>
>>> Hi there,
>>>
>>> With a recent addition to the build scripts, to test lucene backwards
>>> compatibility, a step was added to download a previous version of GEODE.
>>>
>>> This is causing longer build times now, which is a real distraction. In
>>> cases where one would like to work on a branch, rebase that on develop and
>>> merge that, this step becomes a real time hog.
>>>
>>> I request that we remove this default behavior from a clean build until
>>> we have a better solution to this issue.
>>>
>>> I also believe that if anyone wants to add behavior like this into the
>>> default build, that it at least is discussed on the dev list before
>>> implementing this.
>>>
>>> --Udo
>>>
>>>
>

Re: [DISCUSS] Clean build takes 10minutes to complete now

[Bruce Schuchardt]

The geode-old-versions module was originally created to pull in old 
version jar files into your gradle cache.  This happened only once and 
you were good to go.  I don't think that part should be backed out as it 
has minimal impact and is not affecting build time.


The recent changes for lucene testing seem to be pulling in full 
installations of old versions and these are deleted as part of the 
"clean" gradle task.  That's causing them to be downloaded again each 
time you do a clean  Dan put changes in place so that the files 
aren't downloaded again if you build without cleaning but clearly more 
needs to be done in this area.



On 9/11/17 11:23 AM, Jacob Barrett wrote:

Agreed, integration tests should not be part of the build process. This is 
clearly an integration test.


On Sep 11, 2017, at 11:00 AM, Udo Kohlmeyer  wrote:

Hi there,

With a recent addition to the build scripts, to test lucene backwards 
compatibility, a step was added to download a previous version of GEODE.

This is causing longer build times now, which is a real distraction. In cases 
where one would like to work on a branch, rebase that on develop and merge 
that, this step becomes a real time hog.

I request that we remove this default behavior from a clean build until we have 
a better solution to this issue.

I also believe that if anyone wants to add behavior like this into the default 
build, that it at least is discussed on the dev list before implementing this.

--Udo

Review Request 62248: GEODE-3539: Add test for missing coverage of status locator command

[Ken Howe]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/62248/
---

Review request for geode, Jinmei Liao, Jared Stewart, and Patrick Rhomberg.


Repository: geode


Description
---

New test to replace a legacy test being removed.

Removes some commented out code from other status locator command tests


Diffs
-

  
geode-assembly/src/test/java/org/apache/geode/management/internal/cli/shell/GfshExitCodeStatusCommandsTest.java
 bc309dd3111addebac61305b3e7223bc1ade78f3 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/lifecycle/GfshStatusCommandsIntegrationTest.java
 dd5841f4cffca38da07a11f381cf4174d7264349 


Diff: https://reviews.apache.org/r/62248/diff/1/


Testing
---

precheckin passed


Thanks,

Ken Howe

[Discuss] Investigation of C++ object return types

[David Kimura]

Follow up of attached discussion after more investigation.  I created an
example of returning Cache as shared pointer versus raw value:

https://github.com/dgkimura/geode-native-sandbox

I still like returning by value as it lets the user do what they want with
their object.

// Here user creates object on their stack.
auto c = CacheFactory::createFactory().create();

// Here user creates smart pointer in their heap.
auto cptr =
std::make_shared(CacheFactory::createFactory().create());

Difficulty of implementing this is high due to circular dependencies of
Cache/CacheImpl as well as objects hanging off CacheImpl that return
Cache.  We must be extra careful when dealing with move/copy semantics of
Cache/CacheImpl.

Alternative, is to keep as is and only permit heap allocations from factory
using shared pointers.

Thanks,
David

Build failed in Jenkins: Geode-nightly #952

[Apache Jenkins Server]

See 


Changes:

[jdeppe] GEODE-3586: Fix syntax in uploadArchives task (since gradle 3.5)

[dcavender] GEODE-3587: Enable publishing distribution zip

[jiliao] GEODE-2817: consolidate authorize(*) methods

[jiliao] GEODE-3096: pulling in refactoring work on HttpOperationInvoker

[dschneider] GEODE-3543: refactor ExpiryTask to not call 
GemFireCacheImpl.getInstance

--
[...truncated 114.95 KB...]
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-cq:processTestResources
:geode-cq:testClasses
:geode-cq:checkMissedTests
:geode-cq:spotlessJavaCheck
:geode-cq:spotlessCheck
:geode-cq:test
:geode-cq:check
:geode-cq:build
:geode-cq:distributedTest
:geode-cq:integrationTest
:geode-json:assemble
:geode-json:compileTestJava NO-SOURCE
:geode-json:processTestResources
:geode-json:testClasses
:geode-json:checkMissedTests NO-SOURCE
:geode-json:spotlessJavaCheck
:geode-json:spotlessCheck
:geode-json:test NO-SOURCE
:geode-json:check
:geode-json:build
:geode-json:distributedTest NO-SOURCE
:geode-json:integrationTest NO-SOURCE
:geode-junit:javadoc
:geode-junit:javadocJar
:geode-junit:sourcesJar
:geode-junit:signArchives SKIPPED
:geode-junit:assemble
:geode-junit:compileTestJavaNote: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: 

 uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-junit:processTestResources
:geode-junit:testClasses
:geode-junit:checkMissedTests
:geode-junit:spotlessJavaCheck
:geode-junit:spotlessCheck
:geode-junit:test
:geode-junit:check
:geode-junit:build
:geode-junit:distributedTest
:geode-junit:integrationTest
:geode-lucene:assemble
:geode-lucene:compileTestJavaNote: Some input files use or override a 
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-lucene:processTestResources
:geode-lucene:testClasses
:geode-lucene:checkMissedTests
:geode-lucene:spotlessJavaCheck
:geode-lucene:spotlessCheck
:geode-lucene:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJavaNote: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

:geode-old-client-support:processTestResources NO-SOURCE
:geode-old-client-support:testClasses
:geode-old-client-support:checkMissedTests
:geode-old-client-support:spotlessJavaCheck
:geode-old-client-support:spotlessCheck
:geode-old-client-support:test
:geode-old-client-support:check
:geode-old-client-support:build
:geode-old-client-support:distributedTest
:geode-old-client-support:integrationTest
:geode-old-versions:distributedTest NO-SOURCE
:geode-old-versions:integrationTest NO-SOURCE
:geode-protobuf:assemble
:geode-protobuf:extractIncludeTestProto
:geode-protobuf:extractTestProto UP-TO-DATE
:geode-protobuf:generateTestProto NO-SOURCE
:geode-protobuf:compileTestJavaNote: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-protobuf:processTestResources
:geode-protobuf:testClasses
:geode-protobuf:checkMissedTests
:geode-protobuf:spotlessJavaCheck
:geode-protobuf:spotlessCheck
:geode-protobuf:test
:geode-protobuf:check
:geode-protobuf:build
:geode-protobuf:distributedTest
:geode-protobuf:integrationTest
:geode-pulse:assemble
:geode-pulse:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: 

 uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-pulse:processTestResources
:geode-pulse:testClasses
:geode-pulse:checkMissedTests
:geode-pulse:spotlessJavaCheck
:geode-pulse:spotlessCheck
:geode-pulse:test
:geode-pulse:check
:geode-pulse:build
:geode-pulse:distributedTest
:geode-pulse:integrationTest
:geode-rebalancer:assemble
:geode-rebalancer:compileTestJava