Re: Next steps with flickering tests

[Kirk Lund]

We currently have over 10,000 tests but only about 147 are annotated with
FlakyTest. It probably wouldn't cause precheckin to take much longer. My
main argument for separating the FlakyTests into their own Jenkins build
job is to get the main build job 100% green while we know the FlakyTest
build job might "flicker".

-Kirk


On Tue, Apr 26, 2016 at 1:58 PM, Udo Kohlmeyer 
wrote:

> Depending on the amount of "flaky" tests, this should not increase the
> time too much.
> I forsee these "flaky" tests to be few and far in between. Over time I
> imagine this would be a last resort if we cannot fix the test or even
> improve the test harness to have a clean test space for each test.
>
> --Udo
>
>
> On 27/04/2016 6:42 am, Jens Deppe wrote:
>
>> By running the Flakes with forkEvery 1 won't it extend precheckin by a
>> fair
>> bit? I'd prefer to see two separate builds running.
>>
>> On Tue, Apr 26, 2016 at 11:53 AM, Kirk Lund  wrote:
>>
>> I'm in favor of running the FlakyTests together at the end of precheckin
>>> using forkEvery 1 on them too.
>>>
>>> What about running two nightly builds? One that runs all the non-flaky
>>> UnitTests, IntegrationTests and DistributedTests. Plus another nightly
>>> build that runs only FlakyTests? We can run Jenkins jobs on our local
>>> machines that separates FlakyTests out into its own job too, but I'd like
>>> to see the main nightly build go to 100% green (if that's even possible
>>> without encounter many more flickering tests).
>>>
>>> -Kirk
>>>
>>>
>>> On Tue, Apr 26, 2016 at 11:02 AM, Dan Smith  wrote:
>>>
>>> +1 for separating these out and running them with forkEvery 1.

 I think they should probably still run as part of precheckin and the
 nightly builds though. We don't want this to turn into essentially
 disabling and ignoring these tests.

 -Dan

 On Tue, Apr 26, 2016 at 10:28 AM, Kirk Lund  wrote:

> Also, I don't think there's much value continuing to use the "CI"
>
 label.
>>>
 If

> a test fails in Jenkins, then run the test to see if it fails
>
 consistently.

> If it doesn't, it's flaky. The developer looking at it should try to
> determine the cause of it failing (ie, "it uses thread sleeps or random
> ports with BindExceptions or has short timeouts with probable GC
>
 pause")
>>>
 and include that info when adding the FlakyTest annotation and filing a
> Jira bug with the Flaky label. If the test fails consistently, then
>
 file
>>>
 a

> Jira bug without the Flaky label.
>
> -Kirk
>
>
> On Tue, Apr 26, 2016 at 10:24 AM, Kirk Lund  wrote:
>
> There are quite a few test classes that have multiple test methods
>>
> which
>>>
 are annotated with the FlakyTest category.
>>
>> More thoughts:
>>
>> In general, I think that if any given test fails intermittently then
>>
> it
>>>
 is

> a FlakyTest. A good test should either pass or fail consistently.
>>
> After
>>>
 annotating a test method with FlakyTest, the developer should then add
>>
> the

> Flaky label to corresponding Jira ticket. What we then do with the
>>
> Jira
>>>
 tickets (ie, fix them) is probably more important than deciding if a
>>
> test

> is flaky or not.
>>
>> Rather than try to come up with some flaky process for determining if
>>
> a
>>>
 given test is flaky (ie, "does it have thread sleeps?"), it would be
>>
> better

> to have a wiki page that has examples of flakiness and how to fix them
>>
> ("if

> the test has thread sleeps, then switch to using Awaitility and do
>> this...").
>>
>> -Kirk
>>
>>
>> On Mon, Apr 25, 2016 at 10:51 PM, Anthony Baker 
>>
> wrote:

> Thanks Kirk!
>>>
>>> ~/code/incubator-geode (develop)$ grep -ro "FlakyTest.class" . | grep
>>>
>> -v

> Binary | wc -l | xargs echo "Flake factor:"
>>> Flake factor: 136
>>>
>>> Anthony
>>>
>>>
>>> On Apr 25, 2016, at 9:45 PM, William Markito 

>>> wrote:
>>>
 +1

 Are we also planning to automate the additional build task somehow

>>> ?
>>>
 I'd also suggest creating a wiki page with some stats (like how

>>> many
>>>
 FlakyTests we currently have) and the idea behind this effort so we

>>> can

> keep track and see how it's evolving over time.

 On Mon, Apr 25, 2016 at 6:54 PM, Kirk Lund 

>>> wrote:
>>>
 After completing GEODE-1233, all currently known flickering tests
>
 are

> now
>>>
 annotated with our FlakyTest JUnit Category.
>
> In an effort to divide our build up into multiple build pipelines
>
 that

> are
>>>
 sequential a

Re: Upgrading Gradle to version 2.12

[William Markito]

+1

On Wed, Apr 27, 2016 at 10:41 AM, Jason Huynh  wrote:

> Hello Geode dev list,
>
> As a heads up, I am about to check in a change to upgrade the Gradle
> version to 2.12.  This will address GEODE-1259, GEODE-1085, GEODE-1261.
>
> This change will now make the required minimum Gradle Version the same as
> the version used by the Gradle Wrapper Plugin.  This may affect you if you
> have not been using the gradlew scripts to build Geode.
>
> The review request is at https://reviews.apache.org/r/46706/diff/1/
>
> Thanks,
> -Jason
>



-- 

~/William

Fixed: apache/incubator-geode#437 (develop - ecbbf76)

[Travis CI]

Build Update for apache/incubator-geode
-

Build: #437
Status: Fixed

Duration: 16 minutes and 42 seconds
Commit: ecbbf76 (develop)
Author: nabarun
Message: GEODE-1262: Removed VM5-VM7 in AsyncEventQueueTestBase

* Refactored all the test cases to use lower numbered VMs
* VM5-VM7 were unused hence removed from AsyncEventQueueTestBase

This closes #137

View the changeset: 
https://github.com/apache/incubator-geode/compare/20117a803870...ecbbf7660f35

View the full build log and details: 
https://travis-ci.org/apache/incubator-geode/builds/126254702

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

Fixed: apache/incubator-geode#436 (develop - 20117a8)

[Travis CI]

Build Update for apache/incubator-geode
-

Build: #436
Status: Fixed

Duration: 16 minutes and 46 seconds
Commit: 20117a8 (develop)
Author: nabarun
Message: GEODE-710: Replaced thread.sleep with Awaitility

* Replaced thread.sleep with awaitility.
* Place an awaitility to wait for the isCancelled flag to be true before
checking the counter values.

This closes #134

View the changeset: 
https://github.com/apache/incubator-geode/compare/46535f28e474...20117a803870

View the full build log and details: 
https://travis-ci.org/apache/incubator-geode/builds/126252495

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

[GitHub] incubator-geode pull request: GEODE-1262: Removed VM5-VM7 in Async...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-geode/pull/137


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] incubator-geode pull request: GEODE-1059: PRQueryDUnitHelper no lo...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-geode/pull/132


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] incubator-geode pull request: GEODE-710: Replaced thread.sleep wit...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-geode/pull/134


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] incubator-geode pull request: GEODE-935: Removed the sleeps to spe...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-geode/pull/133


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] incubator-geode pull request: GEODE-1258: Added tests for WAN auth...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-geode/pull/131


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: @since tags in our javadocs - old gemfire vs. geode versions

[Dan Smith]

Our code style guide already says that you need to add @since tags to new
public API methods. But maybe we should clarify some of the things you
asked about - class vs. method, etc.

https://cwiki.apache.org/confluence/display/GEODE/Public+APIs

-Dan

On Wed, Apr 27, 2016 at 3:57 PM, Kirk Lund  wrote:

> Do we know if the external user APIs are consistently marked with @since
> tags? If only some of these APIs have @since tags then they don't have much
> value.
>
> If we're going to keep these tags then we should keep them up-to-date and
> have them consistently applied to all of our external user APIs. We should
> then add it to our DOD and code style guidelines. If the DOD and guidelines
> don't specify this then as developers add new classes and methods, we run
> the risk of not consistently having them in place or in how they are used.
>
> For example, if I add a new class to the external user API, should I mark
> all public methods with @since tags or just the class and what about
> protected methods?
>
> -Kirk
>
>
> On Tue, Apr 26, 2016 at 4:23 PM, Dan Smith  wrote:
>
> > I think they may be helpful in the public API - to be able to tell if you
> > are using a feature that has been around for a while, or to realize what
> > version you need to upgrade to in order to get a feature.
> >
> > -Dan
> >
> > On Tue, Apr 26, 2016 at 4:12 PM, Udo Kohlmeyer 
> > wrote:
> >
> > > Just for my own curiosity... why do we need the @since tag?
> > > What benefit does it provide the product/code?
> > >
> > > --Udo
> > >
> > >
> > > On 27/04/2016 7:43 am, Dan Smith wrote:
> > >
> > >> It sounds like more people are in favor of Geode 1.0.0 and GemFire
> > x.y.z,
> > >> so I created bug GEODE-1316 to implement this change.
> > >>
> > >> -Dan
> > >>
> > >> On Mon, Apr 25, 2016 at 6:36 PM, Udo Kohlmeyer  >
> > >> wrote:
> > >>
> > >> I must be honest that I've never been a supporter of the @since tag.
> > Imo,
> > >>> release notes and features should be the paper trail that we provide.
> > >>> Also,
> > >>> how would we handle a scenario where a class is denoted with @since
> > 6.5.x
> > >>> and all internals of that class are completely new and replaced with
> > >>> 8.2.x
> > >>> or even 9.0 (or 1.0 Geode) code?
> > >>>
> > >>> I think that @since tags become like comments, without somebody
> > changing
> > >>> things, they just become stale and stagnant. I cannot think of many
> > open
> > >>> source projects that use @since tags.
> > >>>
> > >>> But if we must have them in the code base then I prefer to have them
> > as a
> > >>> Geode x.y.z
> > >>>
> > >>>
> > >>> On 26/04/2016 9:56 am, Darrel Schneider wrote:
> > >>>
> > >>> +1 for having on explicit GemFire and Geode
> > 
> > 
> >  On Mon, Apr 25, 2016 at 4:43 PM, Kenneth Howe 
> > wrote:
> > 
> >  +1 to “gemFire x.y.z”
> > 
> > > Adding the GemFire makes it obvious where the feature came from, no
> > > inference
> > > required as would happen if we left just a version number for old
> > > @since
> > > annotations.
> > >
> > > Ken
> > >
> > > On Apr 25, 2016, at 4:39 PM, Kirk Lund  wrote:
> > >
> > >> +1 for @since Geode 1.0.0
> > >>
> > >> If we keep the pre-existing @since tags, then I'd prefer to add
> > >> "GemFire"
> > >> to them for better clarity. Thus, @since 4.0.0 would be changed to
> > >> @since
> > >> GemFire 4.0.0. Just my preference.
> > >>
> > >> -Kirk
> > >>
> > >>
> > >> On Mon, Apr 25, 2016 at 4:32 PM, Sai Boorlagadda <
> > >>
> > >> sboorlaga...@pivotal.io>
> > >
> > > wrote:
> > >>
> > >> +1 for Geode 1.0.0
> > >>
> > >>> And we can leave current @since tags as-is with out "GemFire" to
> > >>> denote
> > >>> predate Geode.
> > >>> So if you see "Geode x.y.z" => added in Geode
> > >>>or   "x.y.z" => Predate to Geode
> > >>> (i.e.,)
> > >>> GemFire.
> > >>>
> > >>>
> > >>> On Fri, Apr 22, 2016 at 3:37 PM, John Blum 
> > wrote:
> > >>>
> > >>> +1 for @since Geode 1.0.0.
> > >>>
> >  @since GemFire x.y.z is probably not all that useful from a
> Geode
> >  perspective, but maybe important in GemFire source, particularly
> > for
> >  features that maybe specific to GemFire, or predate Geode.
> > 
> >  On Fri, Apr 22, 2016 at 3:11 PM, Dan Smith <
> >  upthewatersp...@apache.org
> >  wrote:
> > 
> >  Hi,
> > 
> > > We have a lot of @since tags in our javadocs with old gemfire
> > > versions. I think we are going to keep them in there, we should
> > > maybe
> > > do a sweep and add gemfire to the version:
> > >
> > > Eg
> > > @since GemFire 5.5
> > >
> > > For geode @since tags, we can start from 1.0:
> > > @since 1.0
> > >
> > > Or maybe it would be better to b

Re: @since tags in our javadocs - old gemfire vs. geode versions

[Kirk Lund]

Do we know if the external user APIs are consistently marked with @since
tags? If only some of these APIs have @since tags then they don't have much
value.

If we're going to keep these tags then we should keep them up-to-date and
have them consistently applied to all of our external user APIs. We should
then add it to our DOD and code style guidelines. If the DOD and guidelines
don't specify this then as developers add new classes and methods, we run
the risk of not consistently having them in place or in how they are used.

For example, if I add a new class to the external user API, should I mark
all public methods with @since tags or just the class and what about
protected methods?

-Kirk


On Tue, Apr 26, 2016 at 4:23 PM, Dan Smith  wrote:

> I think they may be helpful in the public API - to be able to tell if you
> are using a feature that has been around for a while, or to realize what
> version you need to upgrade to in order to get a feature.
>
> -Dan
>
> On Tue, Apr 26, 2016 at 4:12 PM, Udo Kohlmeyer 
> wrote:
>
> > Just for my own curiosity... why do we need the @since tag?
> > What benefit does it provide the product/code?
> >
> > --Udo
> >
> >
> > On 27/04/2016 7:43 am, Dan Smith wrote:
> >
> >> It sounds like more people are in favor of Geode 1.0.0 and GemFire
> x.y.z,
> >> so I created bug GEODE-1316 to implement this change.
> >>
> >> -Dan
> >>
> >> On Mon, Apr 25, 2016 at 6:36 PM, Udo Kohlmeyer 
> >> wrote:
> >>
> >> I must be honest that I've never been a supporter of the @since tag.
> Imo,
> >>> release notes and features should be the paper trail that we provide.
> >>> Also,
> >>> how would we handle a scenario where a class is denoted with @since
> 6.5.x
> >>> and all internals of that class are completely new and replaced with
> >>> 8.2.x
> >>> or even 9.0 (or 1.0 Geode) code?
> >>>
> >>> I think that @since tags become like comments, without somebody
> changing
> >>> things, they just become stale and stagnant. I cannot think of many
> open
> >>> source projects that use @since tags.
> >>>
> >>> But if we must have them in the code base then I prefer to have them
> as a
> >>> Geode x.y.z
> >>>
> >>>
> >>> On 26/04/2016 9:56 am, Darrel Schneider wrote:
> >>>
> >>> +1 for having on explicit GemFire and Geode
> 
> 
>  On Mon, Apr 25, 2016 at 4:43 PM, Kenneth Howe 
> wrote:
> 
>  +1 to “gemFire x.y.z”
> 
> > Adding the GemFire makes it obvious where the feature came from, no
> > inference
> > required as would happen if we left just a version number for old
> > @since
> > annotations.
> >
> > Ken
> >
> > On Apr 25, 2016, at 4:39 PM, Kirk Lund  wrote:
> >
> >> +1 for @since Geode 1.0.0
> >>
> >> If we keep the pre-existing @since tags, then I'd prefer to add
> >> "GemFire"
> >> to them for better clarity. Thus, @since 4.0.0 would be changed to
> >> @since
> >> GemFire 4.0.0. Just my preference.
> >>
> >> -Kirk
> >>
> >>
> >> On Mon, Apr 25, 2016 at 4:32 PM, Sai Boorlagadda <
> >>
> >> sboorlaga...@pivotal.io>
> >
> > wrote:
> >>
> >> +1 for Geode 1.0.0
> >>
> >>> And we can leave current @since tags as-is with out "GemFire" to
> >>> denote
> >>> predate Geode.
> >>> So if you see "Geode x.y.z" => added in Geode
> >>>or   "x.y.z" => Predate to Geode
> >>> (i.e.,)
> >>> GemFire.
> >>>
> >>>
> >>> On Fri, Apr 22, 2016 at 3:37 PM, John Blum 
> wrote:
> >>>
> >>> +1 for @since Geode 1.0.0.
> >>>
>  @since GemFire x.y.z is probably not all that useful from a Geode
>  perspective, but maybe important in GemFire source, particularly
> for
>  features that maybe specific to GemFire, or predate Geode.
> 
>  On Fri, Apr 22, 2016 at 3:11 PM, Dan Smith <
>  upthewatersp...@apache.org
>  wrote:
> 
>  Hi,
> 
> > We have a lot of @since tags in our javadocs with old gemfire
> > versions. I think we are going to keep them in there, we should
> > maybe
> > do a sweep and add gemfire to the version:
> >
> > Eg
> > @since GemFire 5.5
> >
> > For geode @since tags, we can start from 1.0:
> > @since 1.0
> >
> > Or maybe it would be better to be explicit?
> > @since Geode 1.0
> >
> > What do you guys think?
> > -Dan
> >
> >
> > --
>  -John
>  503-504-8657
>  john.blum10101 (skype)
> 
> 
>  --
> >>> Sai Boorlagadda
> >>>
> >>>
> >>>
> >
>

Geode Clubhouse next Weds, May 4, 9AM PDT - Where Does Geode Fit in Modern System Architectures?

[Gregory Chase]

It's time for the next Apache Geode Clubhouse Meeting on May 4th!

Each meeting starts with a user technology discussion topic, followed by a
contributor & committer discussion of open JIRA issues, release
coordination, and open Q&A.

User Tech Talk: Where Does Geode Fit in Modern System Architectures

Eitan Suez, consulting instructor and deveoper with Pivotal will recap his
talk from Geode Summit covering: Geode in context of a CQRS architecture.

About the speaker: Eitan is a long time developer, instructor and
consultant.  Prior to Pivotal he was a principal consultant helping
customers develop applications based on GemFire.

Standing agenda:

-Open Jiras, and ways to contribute
-Next release coordination
-Open Q&A

Please join us on May 4th, 2016 at:
https://pivotalcommunity.adobeconnect.com/clubhouse/

5/4 San Francisco, CA 9:00 AM PDT UTC-8 hours
5/4 New York, NY 12:00 PM EDT UTC-5 hours

As always, this meeting will be recorded and posted.


Adobe Connect tips: For issues with Chrome.  A little icon appears in the
address bar.  It's EASY to miss. You click it and it allows Adobe to use
the mic, even if you select 'allow' in the popup, it doesn't work until you
change it in address bar too.

Also, preload as much content as is possible to help bandwidth issues.

If you have never attended an Adobe Connect meeting before:

Test your connection:
https://pivotalcommunity.adobeconnect.com/common/help/en/support/meeting_test.htm

Get a quick overview: http://www.adobe.com/products/adobeconnect.html


-- 
Greg Chase

Global Head, Big Data Communities
http://www.pivotal.io/big-data

Pivotal Software
http://www.pivotal.io/

650-215-0477
@GregChase
Blog: http://geekmarketing.biz/

Re: [DISCUSS] What to do with the partial HDFS related code on develop?

[Udo Kohlmeyer]

+1

On 28/04/2016 7:16 am, Dan Smith wrote:

This is done. The HDFS related changes are gone from develop and are now on
their own feature branch - feature/GEODE-10.

-Dan

On Sat, Mar 19, 2016 at 2:05 AM,  wrote:


+1
a possible HDFS integration should also be an optional jar plugin package
in the distribution as Fred started the discussion to split jars anyway.

Best Regards
Manuel Birke

Mercedes-Benz Research & Development North America, Inc.
Address: 309 N Pastoria Ave | Sunnyvale, CA 94085
Mobile: +1 408-203-6026
Phone: +1 408-991-6502

From: Anilkumar Gingade
Sent: ‎3/‎19/‎2016 0:05
To: dev@geode.incubator.apache.org
Subject: Re: [DISCUSS] What to do with the partial HDFS related code on
develop?

+1
Good idea...It will allow us to re-visit the HDFS implementation and right
way to provide this support...

-Anil.






On Fri, Mar 18, 2016 at 3:56 PM, Dan Smith  wrote:


When geode was donated to apache, there was a partially completed
integration with HDFS built in. See GEODE-10.

Since that initial donation, we have removed the APIs related to creating
HDFS regions because they were not yet stable. See GEODE-429.

The problem is that we still have HDFS related code sprinkled throughout
geode-core. This causes us to pull in a bunch of compile dependencies on
hbase and hadoop.

I already created an issue, GEODE-1072, to move the HDFS code it it's own
subproject, but that will take a lot of work.

In the mean time, I propose we go ahead and create a separate branch for
the HDFS related changes and remove the HDFS related code from develop.

The

work to refactor the HDFS integration to be a subproject can take place

on

that branch and geode-core on develop will be cleaner in the mean time.

What do you folks think?

-Dan


If you are not the addressee, please inform us immediately that you have
received this e-mail by mistake, and delete it. We thank you for your
support.

Re: [DISCUSS] What to do with the partial HDFS related code on develop?

[Gregory Chase]

This is a topic we didn't cover at Geode Summit.  We could bring it up at a
Geode Clubhouse if anyone is interested.

On Wed, Apr 27, 2016 at 2:16 PM, Dan Smith  wrote:

> This is done. The HDFS related changes are gone from develop and are now on
> their own feature branch - feature/GEODE-10.
>
> -Dan
>
> On Sat, Mar 19, 2016 at 2:05 AM,  wrote:
>
> > +1
> > a possible HDFS integration should also be an optional jar plugin package
> > in the distribution as Fred started the discussion to split jars anyway.
> >
> > Best Regards
> > Manuel Birke
> >
> > Mercedes-Benz Research & Development North America, Inc.
> > Address: 309 N Pastoria Ave | Sunnyvale, CA 94085
> > Mobile: +1 408-203-6026
> > Phone: +1 408-991-6502
> > 
> > From: Anilkumar Gingade
> > Sent: ‎3/‎19/‎2016 0:05
> > To: dev@geode.incubator.apache.org >
> > Subject: Re: [DISCUSS] What to do with the partial HDFS related code on
> > develop?
> >
> > +1
> > Good idea...It will allow us to re-visit the HDFS implementation and
> right
> > way to provide this support...
> >
> > -Anil.
> >
> >
> >
> >
> >
> >
> > On Fri, Mar 18, 2016 at 3:56 PM, Dan Smith  wrote:
> >
> > > When geode was donated to apache, there was a partially completed
> > > integration with HDFS built in. See GEODE-10.
> > >
> > > Since that initial donation, we have removed the APIs related to
> creating
> > > HDFS regions because they were not yet stable. See GEODE-429.
> > >
> > > The problem is that we still have HDFS related code sprinkled
> throughout
> > > geode-core. This causes us to pull in a bunch of compile dependencies
> on
> > > hbase and hadoop.
> > >
> > > I already created an issue, GEODE-1072, to move the HDFS code it it's
> own
> > > subproject, but that will take a lot of work.
> > >
> > > In the mean time, I propose we go ahead and create a separate branch
> for
> > > the HDFS related changes and remove the HDFS related code from develop.
> > The
> > > work to refactor the HDFS integration to be a subproject can take place
> > on
> > > that branch and geode-core on develop will be cleaner in the mean time.
> > >
> > > What do you folks think?
> > >
> > > -Dan
> > >
> >
> > If you are not the addressee, please inform us immediately that you have
> > received this e-mail by mistake, and delete it. We thank you for your
> > support.
> >
> >
>



-- 
Greg Chase

Global Head, Big Data Communities
http://www.pivotal.io/big-data

Pivotal Software
http://www.pivotal.io/

650-215-0477
@GregChase
Blog: http://geekmarketing.biz/

Re: [DISCUSS] What to do with the partial HDFS related code on develop?

[Dan Smith]

This is done. The HDFS related changes are gone from develop and are now on
their own feature branch - feature/GEODE-10.

-Dan

On Sat, Mar 19, 2016 at 2:05 AM,  wrote:

> +1
> a possible HDFS integration should also be an optional jar plugin package
> in the distribution as Fred started the discussion to split jars anyway.
>
> Best Regards
> Manuel Birke
>
> Mercedes-Benz Research & Development North America, Inc.
> Address: 309 N Pastoria Ave | Sunnyvale, CA 94085
> Mobile: +1 408-203-6026
> Phone: +1 408-991-6502
> 
> From: Anilkumar Gingade
> Sent: ‎3/‎19/‎2016 0:05
> To: dev@geode.incubator.apache.org
> Subject: Re: [DISCUSS] What to do with the partial HDFS related code on
> develop?
>
> +1
> Good idea...It will allow us to re-visit the HDFS implementation and right
> way to provide this support...
>
> -Anil.
>
>
>
>
>
>
> On Fri, Mar 18, 2016 at 3:56 PM, Dan Smith  wrote:
>
> > When geode was donated to apache, there was a partially completed
> > integration with HDFS built in. See GEODE-10.
> >
> > Since that initial donation, we have removed the APIs related to creating
> > HDFS regions because they were not yet stable. See GEODE-429.
> >
> > The problem is that we still have HDFS related code sprinkled throughout
> > geode-core. This causes us to pull in a bunch of compile dependencies on
> > hbase and hadoop.
> >
> > I already created an issue, GEODE-1072, to move the HDFS code it it's own
> > subproject, but that will take a lot of work.
> >
> > In the mean time, I propose we go ahead and create a separate branch for
> > the HDFS related changes and remove the HDFS related code from develop.
> The
> > work to refactor the HDFS integration to be a subproject can take place
> on
> > that branch and geode-core on develop will be cleaner in the mean time.
> >
> > What do you folks think?
> >
> > -Dan
> >
>
> If you are not the addressee, please inform us immediately that you have
> received this e-mail by mistake, and delete it. We thank you for your
> support.
>
>

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #292 has FAILED

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #292 failed.
---
Scheduled
No failed tests found, a possible compilation error.

https://build.spring.io/browse/SGF-NAG-292/

-
Currently Responsible
-

John Blum 



--
Failing Jobs
--
  - Default Job (Default Stage): No tests found.




--
This message is automatically generated by Atlassian Bamboo

Re: Its been a year....

[Jens Deppe]

 
via giphy.com 

On Wed, Apr 27, 2016 at 12:31 PM, Greg Chase  wrote:

> Can someone cook up a birthday cake?
>
> This email encrypted by tiny buttons & fat thumbs, beta voice recognition,
> and autocorrect on my iPhone.
>
> > On Apr 27, 2016, at 12:27 PM, Roman Shaposhnik 
> wrote:
> >
> > Hear! Hear! An amazing community journey!
> >
> > Here's to the TLP and world domination! ;-)
> >
> > Thanks,
> > Roman.
> >
> >> On Wed, Apr 27, 2016 at 11:31 AM, Anilkumar Gingade <
> aging...@pivotal.io> wrote:
> >> Hi Geode,
> >>
> >> Thought of sharing this milestone...
> >>
> >> Wow...Its been a year...In last year ApacheCON (Apr 2015) we announced
> open
> >> sourcing Geode, we made the Geode source available to the Apache
> >> community...Its been a great journey from that point...
> >>
> >> The geode community is growing and contributing to the Geode code
> >> base...Thanks to all the developers and community, we have successfully
> >> achieved two milestone releases and heading towards Graduations...
> >>
> >> Great work team and contributors...
> >>
> >> Thanks,
> >> -Anil.
> >>
> >>
> >>
> >>
>

User Defined Aggregate (UDA) function support in Geode OQL

[Anilkumar Gingade]

Hi Geode Devs,

To enhance Geode query functionalities; we had started initiative to
support Aggregate and UDA functionalities using a common frame work.

The spec for this can be found at:
https://cwiki.apache.org/confluence/display/GEODE/OQL+Aggregate+functions+and+UDA

As part of first phase implementation, we added common frame-work and
support for standard aggregate functions like Min, Max, Avg and Sum, which
is available in the Geode develop branch.

As a second phase implementation, we have added support for UDAs which is
available as feature branch.

feature/GEODE-1269

We are looking for input, comments and contribution to that UDA
functionality, try it and let us know your feedback.

Thanks,
-Anil.

Re: Its been a year....

[Greg Chase]

Can someone cook up a birthday cake?

This email encrypted by tiny buttons & fat thumbs, beta voice recognition, and 
autocorrect on my iPhone.

> On Apr 27, 2016, at 12:27 PM, Roman Shaposhnik  wrote:
> 
> Hear! Hear! An amazing community journey!
> 
> Here's to the TLP and world domination! ;-)
> 
> Thanks,
> Roman.
> 
>> On Wed, Apr 27, 2016 at 11:31 AM, Anilkumar Gingade  
>> wrote:
>> Hi Geode,
>> 
>> Thought of sharing this milestone...
>> 
>> Wow...Its been a year...In last year ApacheCON (Apr 2015) we announced open
>> sourcing Geode, we made the Geode source available to the Apache
>> community...Its been a great journey from that point...
>> 
>> The geode community is growing and contributing to the Geode code
>> base...Thanks to all the developers and community, we have successfully
>> achieved two milestone releases and heading towards Graduations...
>> 
>> Great work team and contributors...
>> 
>> Thanks,
>> -Anil.
>> 
>> 
>> 
>> 

Re: Its been a year....

[Roman Shaposhnik]

Hear! Hear! An amazing community journey!

Here's to the TLP and world domination! ;-)

Thanks,
Roman.

On Wed, Apr 27, 2016 at 11:31 AM, Anilkumar Gingade  wrote:
> Hi Geode,
>
> Thought of sharing this milestone...
>
> Wow...Its been a year...In last year ApacheCON (Apr 2015) we announced open
> sourcing Geode, we made the Geode source available to the Apache
> community...Its been a great journey from that point...
>
> The geode community is growing and contributing to the Geode code
> base...Thanks to all the developers and community, we have successfully
> achieved two milestone releases and heading towards Graduations...
>
> Great work team and contributors...
>
> Thanks,
> -Anil.
>
>
>
>

Its been a year....

[Anilkumar Gingade]

Hi Geode,

Thought of sharing this milestone...

Wow...Its been a year...In last year ApacheCON (Apr 2015) we announced open
sourcing Geode, we made the Geode source available to the Apache
community...Its been a great journey from that point...

The geode community is growing and contributing to the Geode code
base...Thanks to all the developers and community, we have successfully
achieved two milestone releases and heading towards Graduations...

Great work team and contributors...

Thanks,
-Anil.

Upgrading Gradle to version 2.12

[Jason Huynh]

Hello Geode dev list,

As a heads up, I am about to check in a change to upgrade the Gradle
version to 2.12.  This will address GEODE-1259, GEODE-1085, GEODE-1261.

This change will now make the required minimum Gradle Version the same as
the version used by the Gradle Wrapper Plugin.  This may affect you if you
have not been using the gradlew scripts to build Geode.

The review request is at https://reviews.apache.org/r/46706/diff/1/

Thanks,
-Jason

Re: Review Request 46706: GEODE-1259: Upgrade gradle version to 2.12

[Jason Huynh]

> On April 27, 2016, 1:46 p.m., Anthony Baker wrote:
> > settings.gradle, line 38
> > 
> >
> > If you define this as 'ext.minimumGradleVersion' can we avoid setting 
> > it both here and in gradle.properties?

I moved the minimumGradleVersion to gradle.properties and removed the one in 
settings.gradle.  Was there a reason to keep it in settings.gradle instead?


On April 27, 2016, 1:46 p.m., Jason Huynh wrote:
> > After running `gradle wrapper` with the gradleVersion set, the 
> > `gradle/wrapper/gradle-wrapper.jar` is different, probably because it was 
> > generated with different gradle version.  Should that be updated for 
> > consistency?
> > 
> > Since this is a build change that will affect everyone, can you send a 
> > heads up to the dev list?  Thanks!

Added the gradle-wrapper.jar.  I'll send an email before checking in


- Jason


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


On April 26, 2016, 11:12 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46706/
> ---
> 
> (Updated April 26, 2016, 11:12 p.m.)
> 
> 
> Review request for geode, Anthony Baker, anilkumar gingade, Barry Oglesby, 
> Mark Bretl, nabarun nag, Dan Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Addresses GEODE-1085
> Addresses GEODE-1261
> 
> 
> Diffs
> -
> 
>   BUILDING.md ababe2b 
>   build.gradle 4f79eae 
>   gradle.properties 669baed 
>   gradle/wrapper/gradle-wrapper.properties 7b0d17a 
>   settings.gradle c579dce 
> 
> Diff: https://reviews.apache.org/r/46706/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: Review Request 46705: Integrated Security for JMX and commands

[Jens Deppe]

This is a big chunk of code, so I wanted to point out a couple of points of
interest.

APIs are protected with a new @ResourceOperation annotation as can be seen
in CacheServerMXBean:286 for example [1]. The available Resources and
OperationCodes are defined in OperationContext [2]. Where relevant, all
MXBean methods are annotated with @ResourceOperation. The annotation is
both class and method level so defaults can be applied at the class level
and overridden, as needed, per method.

CLI methods are also covered by the same annotation.

All JMX operations are intercepted by a JMXAuthenticator
(JMXShiroAuthenticator) [3] for authentication and a MBeanServerForwarder
(MBeanServerWrapper) [4] for authorization.

REST Admin API calls (as used by gfsh over http) are authenticated with a
Spring Interceptor (EnvironmentVariablesHandlerInterceptor) [5] - this
should probably be renamed. REST calls ultimately always invoke MBean
methods and are thus authorized through the same path as JMX calls.

We've introduced Apache Shiro [6] as a security management framework. It's
used very lightly right now, but eventually we want to have all of Geode
security use it as we extend it to also cover the client/server security
aspects of Geode.

Thanks for taking the time to review.

--Jens

[1] https://reviews.apache.org/r/46705/diff/1#17
[2] https://reviews.apache.org/r/46705/diff/1#5
[3] https://reviews.apache.org/r/46705/diff/1/?page=5#86
[4] https://reviews.apache.org/r/46705/diff/1?page=4#65
[5] https://reviews.apache.org/r/46705/diff/1?page=4#78
[6] http://shiro.apache.org/

On Tue, Apr 26, 2016 at 9:20 AM, Jinmei Liao  wrote:

>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46705/
> ---
>
> Review request for geode.
>
>
> Repository: geode
>
>
> Description
> ---
>
> integration security for JMX and commands
> *shiro security
> *Clean up resource and operation code for permission checking
>
>
> Diffs
> -
>
>   geode-assembly/build.gradle e849b51
>
> geode-assembly/src/test/java/com/gemstone/gemfire/management/internal/cli/commands/LauncherLifecycleCommandsDUnitTest.java
> b394063
>
> geode-assembly/src/test/java/com/gemstone/gemfire/management/internal/configuration/SharedConfigurationEndToEndDUnitTest.java
> e1093a2
>   geode-assembly/src/test/resources/expected_jars.txt 159d1e6
>   geode-core/build.gradle 2206018
>
> geode-core/src/main/java/com/gemstone/gemfire/cache/operations/OperationContext.java
> 9482d6b
>
> geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/AbstractDistributionConfig.java
> c742005
>
> geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/ConfigAttribute.java
> 51712f9
>
> geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/ConfigAttributeChecker.java
> 14c1e54
>
> geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/ConfigAttributeDesc.java
> 57a4a72
>
> geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/ConfigAttributeGetter.java
> 678ecf0
>
> geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/ConfigAttributeSetter.java
> ad8ad65
>
> geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/DistributionConfig.java
> c1a96ea
>
> geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/DistributionConfigImpl.java
> 2f0e1d9
>
> geode-core/src/main/java/com/gemstone/gemfire/internal/AbstractConfig.java
> 09fc61c
>
> geode-core/src/main/java/com/gemstone/gemfire/internal/security/AuthorizeRequest.java
> 8e550d4
>
> geode-core/src/main/java/com/gemstone/gemfire/management/AsyncEventQueueMXBean.java
> e96d78c
>
> geode-core/src/main/java/com/gemstone/gemfire/management/CacheServerMXBean.java
> 8255a93
>
> geode-core/src/main/java/com/gemstone/gemfire/management/DiskStoreMXBean.java
> 79ff056
>
> geode-core/src/main/java/com/gemstone/gemfire/management/DistributedLockServiceMXBean.java
> 317ee33
>
> geode-core/src/main/java/com/gemstone/gemfire/management/DistributedRegionMXBean.java
> 3003827
>
> geode-core/src/main/java/com/gemstone/gemfire/management/DistributedSystemMXBean.java
> a6f65d4
>
> geode-core/src/main/java/com/gemstone/gemfire/management/GatewayReceiverMXBean.java
> 519db6c
>
> geode-core/src/main/java/com/gemstone/gemfire/management/GatewaySenderMXBean.java
> 33c47a4
>
> geode-core/src/main/java/com/gemstone/gemfire/management/LocatorMXBean.java
> ec4dd88
>
> geode-core/src/main/java/com/gemstone/gemfire/management/LockServiceMXBean.java
> 85a8e75
>
> geode-core/src/main/java/com/gemstone/gemfire/management/ManagerMXBean.java
> 7272c8c
>
> geode-core/src/main/java/com/gemstone/gemfire/management/MemberMXBean.java
> ed27569
>
> geode-core/src/main/java/com/gemstone/gemfire/management/RegionMXBean.java
> 8c11d00
>
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/ManagementAgent.java
> 2547070

Re: Review Request 46636: GEODE-1293: Updating module scripts and structure

[Jens Deppe]

> On April 27, 2016, 12:46 a.m., Dan Smith wrote:
> > I'm not quite sure what this modify_war script is all about, but the rest 
> > of the changes look good to me! Maybe someone else who knows more about 
> > that can take a look.

The script is used to convert an existing .war file so that it works correctly 
with session replication. It modifies the web.xml by adding a required  
element as well as adding the necessary jars into the lib/ directory.


- Jens


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


On April 25, 2016, 7:57 p.m., Jens Deppe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46636/
> ---
> 
> (Updated April 25, 2016, 7:57 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Jason Huynh, nabarun nag, and 
> Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> - Remove cacheserver.sh and gemfire.sh scripts in favor of using gfsh
> - Adjust p2p config to always use locators
> - Have modify_war reference correct jars
> 
> 
> Diffs
> -
> 
>   extensions/geode-modules-assembly/build.gradle 
> 960d9242001df154e23bc8b2bed94a49a980add1 
>   extensions/geode-modules-assembly/release/conf/cache-client.xml 
> c36e0ef4bbd4911a2a3aa0f14e738f82c6737c69 
>   extensions/geode-modules-assembly/release/conf/cache-server.xml 
> 9dad75f4be93bc68e4dec20dc5a7d458c66494c8 
>   extensions/geode-modules-assembly/release/scripts/cacheserver.bat 
> ef7f99fbd79fb00100f8e386eba07507fac0b5f5 
>   extensions/geode-modules-assembly/release/scripts/cacheserver.sh 
> 28edc352792c5dc2ffaad21295ebe16e14e59982 
>   extensions/geode-modules-assembly/release/scripts/gemfire.bat 
> 6102b88363bbff6626cef3309e0cbd5da41eb816 
>   extensions/geode-modules-assembly/release/scripts/gemfire.sh 
> 12956cc7af0890d6128f290f78dd4e8e6fdab82b 
>   extensions/geode-modules-assembly/release/scripts/setenv.properties 
> fc8918b29d4b040559b79769b2da02d37abdc6e8 
>   extensions/geode-modules-assembly/release/session/bin/cacheserver.bat 
> 2935cde7115e0c2565b4d49757c8c25bda1c122e 
>   extensions/geode-modules-assembly/release/session/bin/cacheserver.sh 
> 2c12b57a98f6f796718e4e7f4d1b2abb0a531c21 
>   extensions/geode-modules-assembly/release/session/bin/gemfire.bat 
> a66964cc00e83fe4fd9f073737b5cb5830c2c670 
>   extensions/geode-modules-assembly/release/session/bin/gemfire.sh 
> ac11a4dae1ca97c6e1f96733dca787a6a4884849 
>   extensions/geode-modules-assembly/release/session/bin/modify_war 
> 9c871047fa228dec1265c0ad5365f56d11d1154b 
>   extensions/geode-modules-assembly/release/session/bin/setenv.properties 
> fc8918b29d4b040559b79769b2da02d37abdc6e8 
>   
> extensions/geode-modules-assembly/release/tcserver/gemfire-cs-tomcat-7/context-fragment.xml
>   
>   
> extensions/geode-modules-assembly/release/tcserver/gemfire-cs-tomcat-7/modules.env
>  1c14a6c1e1fc0fec05bbef4198b9a5441aa472e7 
>   
> extensions/geode-modules-assembly/release/tcserver/gemfire-cs-tomcat-8/context-fragment.xml
>   
>   
> extensions/geode-modules-assembly/release/tcserver/gemfire-cs-tomcat-8/modules.env
>  d2206756d3d0fb5146d4f8e76e3dad0a85e9887b 
>   
> extensions/geode-modules-assembly/release/tcserver/gemfire-cs/configuration-prompts.properties
>  0ebae9730e9d9fa88959f566bbf996d4f968ef99 
>   
> extensions/geode-modules-assembly/release/tcserver/gemfire-cs/context-fragment.xml
>   
>   extensions/geode-modules-assembly/release/tcserver/gemfire-cs/modules.env 
> 9c4c00a99b4af9f8294b0a0be65588d7727e7e5a 
>   
> extensions/geode-modules-assembly/release/tcserver/gemfire-cs/server-fragment.xml
>   
>   
> extensions/geode-modules-assembly/release/tcserver/gemfire-p2p-tomcat-7/context-fragment.xml
>   
>   
> extensions/geode-modules-assembly/release/tcserver/gemfire-p2p-tomcat-7/modules.env
>  1c14a6c1e1fc0fec05bbef4198b9a5441aa472e7 
>   
> extensions/geode-modules-assembly/release/tcserver/gemfire-p2p-tomcat-8/context-fragment.xml
>   
>   
> extensions/geode-modules-assembly/release/tcserver/gemfire-p2p-tomcat-8/modules.env
>  d2206756d3d0fb5146d4f8e76e3dad0a85e9887b 
>   
> extensions/geode-modules-assembly/release/tcserver/gemfire-p2p/configuration-prompts.properties
>  fdead44e3be7858f4dd982d9323ce74b4d61442c 
>   
> extensions/geode-modules-assembly/release/tcserver/gemfire-p2p/context-fragment.xml
>   
>   extensions/geode-modules-assembly/release/tcserver/gemfire-p2p/modules.env 
> 9c4c00a99b4af9f8294b0a0be65588d7727e7e5a 
>   
> extensions/geode-modules-assembly/release/tcserver/gemfire-p2p/server-fragment.xml
>   
>   extensions/geode-modules-session/build.gradle 
> e301a6a2372d5b9f5ae0da22b57c8e431c4e09ac 
>   
> extensions/geode-modules/src/main/java/com/gemstone/gemfire/modules/

Re: Brew formulae for geode

[Anthony Baker]

There’s a clarification thread here [1].  I’ll followup with the HomeBrew 
peoples and update this thread with the resolution.

Anthony

[1] 
http://mail-archives.apache.org/mod_mbox/incubator-general/201604.mbox/%3cCAEwge-GBVo5fVW7bXniwUXS-=F=lqfvhcskaur51cxo4ysv...@mail.gmail.com%3e

> On Apr 23, 2016, at 10:36 PM, Roman Shaposhnik  wrote:
> 
> On Sat, Apr 23, 2016 at 10:27 PM, Anthony Baker  wrote:
>> I can go either way, but the brew maintainers seem to prefer without the 
>> apache- prefix:
>> https://github.com/Homebrew/brew/blob/master/share/doc/homebrew/Formula-Cookbook.md
>> 
>> Out of 57 Apache projects on Homebrew, only 6 use the apache- prefix:
>> 
>> Anthony-Baker-MacBook-Pro:Formula abaker$ ls -1 apache* | wc -l
>>   6
> 
> Not sure where how you're getting your # but
>   $ brew search apache
> apache-activemqapache-forrest
> apache-archiva apache-opennlp
> apache-drill   apache-spark
> apache-fop apachetop
> 
>> Anthony-Baker-MacBook-Pro:Formula abaker$ grep -i apache * | grep homepage | 
>> wc -l
>>  57
> 
> Well, personally I see that the rest of the projects are either way more
> unique in their naming than geode or are older generation (the time
> when branding requirements were less prominent).
> 
> But I'm with you -- I was on the fence when I was writing the email myself.
> What convinced me to ask you to name it apache-geode was seeing
> apache-spark and apache-drill.
> 
> Thanks,
> Roman.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Review Request 46706: GEODE-1259: Upgrade gradle version to 2.12

[Anthony Baker]

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




settings.gradle 


If you define this as 'ext.minimumGradleVersion' can we avoid setting it 
both here and in gradle.properties?


After running `gradle wrapper` with the gradleVersion set, the 
`gradle/wrapper/gradle-wrapper.jar` is different, probably because it was 
generated with different gradle version.  Should that be updated for 
consistency?

Since this is a build change that will affect everyone, can you send a heads up 
to the dev list?  Thanks!

- Anthony Baker


On April 26, 2016, 11:12 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46706/
> ---
> 
> (Updated April 26, 2016, 11:12 p.m.)
> 
> 
> Review request for geode, Anthony Baker, anilkumar gingade, Barry Oglesby, 
> Mark Bretl, nabarun nag, Dan Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Addresses GEODE-1085
> Addresses GEODE-1261
> 
> 
> Diffs
> -
> 
>   BUILDING.md ababe2b 
>   build.gradle 4f79eae 
>   gradle.properties 669baed 
>   gradle/wrapper/gradle-wrapper.properties 7b0d17a 
>   settings.gradle c579dce 
> 
> Diff: https://reviews.apache.org/r/46706/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: Build failed in Jenkins: Geode-spark-connector #18

[Anthony Baker]

Looks like this worker has an invalid settings.xml file.  That file is read to 
obtain the credentials for uploading maven artifacts.

Anthony

> On Apr 27, 2016, at 6:20 AM, Apache Jenkins Server 
>  wrote:
> 
> See 
> 
> Changes:
> 
> [bschuchardt] GEODE-1237 remove the check for network-partition-detection 
> uniformity
> 
> [dbarnes] GEODE-54: Missing Javadocs
> 
> [dschneider] GEODE-1304: remove TODO OFFHEAP comments
> 
> [dschneider] GEODE-1238: fix EntryEventImpl already released
> 
> --
> Started by upstream project "Geode-nightly" build number 451
> originally caused by:
> Started by timer
> [EnvInject] - Loading node environment variables.
> Building remotely on jenkins-test-170 (jenkins-cloud-4GB cloud-slave Ubuntu 
> ubuntu jenkins-cloud-8GB) in workspace 
> 
> Cloning the remote Git repository
> Cloning repository https://git-wip-us.apache.org/repos/asf/incubator-geode.git
>> git init  # 
>> timeout=10
> Fetching upstream changes from 
> https://git-wip-us.apache.org/repos/asf/incubator-geode.git
>> git --version # timeout=10
>> git -c core.askpass=true fetch --tags --progress 
>> https://git-wip-us.apache.org/repos/asf/incubator-geode.git 
>> +refs/heads/*:refs/remotes/origin/*
>> git config remote.origin.url 
>> https://git-wip-us.apache.org/repos/asf/incubator-geode.git # timeout=10
>> git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
>> timeout=10
>> git config remote.origin.url 
>> https://git-wip-us.apache.org/repos/asf/incubator-geode.git # timeout=10
> Fetching upstream changes from 
> https://git-wip-us.apache.org/repos/asf/incubator-geode.git
>> git -c core.askpass=true fetch --tags --progress 
>> https://git-wip-us.apache.org/repos/asf/incubator-geode.git 
>> +refs/heads/*:refs/remotes/origin/*
>> git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
>> git rev-parse refs/remotes/origin/origin/develop^{commit} # timeout=10
> Checking out Revision 39b9edcfea616027eb2dd4de98b7a51d787a4915 
> (refs/remotes/origin/develop)
>> git config core.sparsecheckout # timeout=10
>> git checkout -f 39b9edcfea616027eb2dd4de98b7a51d787a4915 # timeout=10
>> git branch -a # timeout=10
>> git rev-parse remotes/origin/asf-site^{commit} # timeout=10
>> git rev-parse remotes/origin/asf/asf-site^{commit} # timeout=10
>> git rev-parse remotes/origin/develop^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-1017^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-1040^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-1050^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-1056^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-1072^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-1096^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-11^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-1109^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-1153^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-1162^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-1186^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-12^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-1209^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-1233^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-1255^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-1257^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-1269^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-1276^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-14^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-14-2^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-16^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-17^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-17-2^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-178^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-217^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-259^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-308^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-374^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-409^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-417^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-52^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-564^{commit} # timeout=10
>> git rev-parse remotes/origin/feature/GEODE-574^{commit} # timeout=10
>> git rev-parse remotes/origin/featur

Build failed in Jenkins: Geode-spark-connector #18

[Apache Jenkins Server]

See 

Changes:

[bschuchardt] GEODE-1237 remove the check for network-partition-detection 
uniformity

[dbarnes] GEODE-54: Missing Javadocs

[dschneider] GEODE-1304: remove TODO OFFHEAP comments

[dschneider] GEODE-1238: fix EntryEventImpl already released

--
Started by upstream project "Geode-nightly" build number 451
originally caused by:
 Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on jenkins-test-170 (jenkins-cloud-4GB cloud-slave Ubuntu 
ubuntu jenkins-cloud-8GB) in workspace 

Cloning the remote Git repository
Cloning repository https://git-wip-us.apache.org/repos/asf/incubator-geode.git
 > git init  # 
 > timeout=10
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/incubator-geode.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/incubator-geode.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/incubator-geode.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/incubator-geode.git # timeout=10
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/incubator-geode.git
 > git -c core.askpass=true fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/incubator-geode.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/develop^{commit} # timeout=10
Checking out Revision 39b9edcfea616027eb2dd4de98b7a51d787a4915 
(refs/remotes/origin/develop)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 39b9edcfea616027eb2dd4de98b7a51d787a4915 # timeout=10
 > git branch -a # timeout=10
 > git rev-parse remotes/origin/asf-site^{commit} # timeout=10
 > git rev-parse remotes/origin/asf/asf-site^{commit} # timeout=10
 > git rev-parse remotes/origin/develop^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-1017^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-1040^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-1050^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-1056^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-1072^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-1096^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-11^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-1109^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-1153^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-1162^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-1186^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-12^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-1209^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-1233^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-1255^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-1257^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-1269^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-1276^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-14^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-14-2^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-16^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-17^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-17-2^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-178^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-217^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-259^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-308^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-374^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-409^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-417^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-52^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-564^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-574^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-607^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-610^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-639^{commit} # timeout=10
 > git rev-parse remotes/origin/feature/GEODE-678^{commit} # timeout=10
 > git rev-parse r

Jenkins build is back to normal : Geode-nightly #451

[Apache Jenkins Server]

See