FOSDEM 2016 - take action by 4th of December 2015

[Roman Shaposhnik]

As most of you probably know FOSDEM 2016 (the biggest,
100% free open source developer conference) is right 
around the corner:
   https://fosdem.org/2016/

We hope to have an ASF booth and we would love to see as
many ASF projects as possible present at various tracks
(AKA Developer rooms):
   https://fosdem.org/2016/schedule/#devrooms

This year, for the first time, we are running a dedicated
Big Data and HPC Developer Room and given how much of that
open source development is done at ASF it would be great
to have folks submit talks to:
   https://hpc-bigdata-fosdem16.github.io

While the CFPs for different Developer Rooms follow slightly 
different schedules, but if you submit by the end of this week 
you should be fine.

Finally if you don't want to fish for CFP submission URL,
here it is:
   https://fosdem.org/submit

If you have any questions -- please email me *directly* and
hope to see as many of you as possible in two months! 

Thanks,
Roman.

Re: Review of 1.0.0-alpha1 issues

[Roman Shaposhnik]

On Mon, Nov 30, 2015 at 5:39 PM, Anilkumar Gingade  wrote:
> Thanks Nitin,
>
>>> My preference would be for dot releases instead of alpha1, apha2, beta,
> RC, etc. Other thoughts?
> +1 on this...If we are planning to do only one intermediate release before
> 1.0 release (as mike was suggesting) we can call this 0.5.
>
> I had looked into the task/tickets for alpha release; i was trying to see
> if we have any additional intermediate releases and requirement for them.

On the other hand, alpha/beta release labels clearly send signal to your
user community to start testing and providing feedback. Alphas says:
do it now or later, beta says: do it now or forever hold your peace.

This worked well for Hadoop 2.0 release.

Thanks,
Roman.

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #144 was SUCCESSFUL (with 1214 tests)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #144 was successful.
---
Scheduled
1218 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Re: Geode 1.0.0 (alpha1): Open questions

[Roman Shaposhnik]

On Mon, Nov 30, 2015 at 11:36 AM, Nitin Lamba  wrote:
> Wanted to start a thread capturing all the open (mostly process) questions 
> for the first alpha1 release:
>
>
> - Does ASF have Pivotal's (or EMC's, VMware's, Gemstone's) CCLA on file? Who 
> can confirm?
> This is a legal requirement

See what Niall said, but yes Pivotal does have CCLA on file.

> - Is the alternate (podling) release 
> process
> available to Geode? Doesn't look like a popular method but may have 
> advantages to partially automate the
> release manifest through the existing build process

I will advise strongly against using it for the *first* release. Subsequent
releases are fair game for the alt. process.

> - What target build platforms (OS, etc) should be included in this release?
> Echoing the same question that was asked by Karen Miller regarding
> installation documents

Does it really matter that much for a Java project?

Thanks,
Roman.

Re: Review of 1.0.0-alpha1 issues

[Anilkumar Gingade]

Thanks Nitin,

>> My preference would be for dot releases instead of alpha1, apha2, beta,
RC, etc. Other thoughts?
+1 on this...If we are planning to do only one intermediate release before
1.0 release (as mike was suggesting) we can call this 0.5.

I had looked into the task/tickets for alpha release; i was trying to see
if we have any additional intermediate releases and requirement for them.

-Anil.








On Mon, Nov 30, 2015 at 3:28 PM, Nitin Lamba  wrote:

> Thanks Anil,
>
> From the best practices section:
>
> "TODO: (move to a note) Notes on 0.x releases verses alpha and betas. It
> is better to use 0.x releases than to create numerous alphas and betas for
> 1.0. Conventionally, 0.x releases are aimed at early adopters only without
> a strong promise of easy upgrade or backwards compatibility. 0.x is a good
> designation for a product that is not feature complete but whose code is
> solid for those features which are implemented. "
>
> My preference would be for dot releases instead of alpha1, apha2, beta,
> RC, etc. Other thoughts?
>
> As for the release tasks, perhaps you missed the Wiki page:
>
> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-alpha1+%28First%29+Release
>
> The JIRA (Agile) Board is here:
>
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=92&view=planning
>
> Was hoping to get more discussion/ feedback from the community on the Wiki
> before JIRA versions and tasks are created. Please review/ comment the
> contents, if not done already.
>
> Thanks,
> -Nitin
> 
> From: Anilkumar Gingade 
> Sent: Monday, November 30, 2015 2:47 PM
> To: dev@geode.incubator.apache.org
> Subject: Re: Review of 1.0.0-alpha1 issues
>
> Here is more detail on versioning
>
>
> http://incubator.apache.org/guides/releasemanagement.html#best-practice-naming
>  (under versioning section)
>
> Can we set a release task list...
> E.g.: What tasks/items are expected to complete to do an alpha, beta and
> final 1.0 release...
>
> -Anil.
>
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Nov 30, 2015 at 1:33 PM, Anthony Baker  wrote:
>
> >
> > On Nov 30, 2015, at 11:23 AM, Nitin Lamba  wrote:
> >
> > +1
> >
> > I do have a fundamental question about versioning (rather what versions
> > can be taken for voting/ approvals):
> >
> > Can an 'alpha' which has known issues (like GEODE-27 or GEODE-386 for
> > apache namespace, etc) be taken all the way through the PMC process for
> > approvals? Such a release will have to be posted to maven/ apache builds
> > but does it meet the quality requirements for an 'Apache Release’?
> >
> >
> > Good question.  I was assuming we would need to address GEODE-386 before
> > graduation but not for the first release.
> >
> >
> > Also, in the guidelines, I've seen references to dot releases 0.x.y up to
> > the 1.0 release but not 'alpha1', 'alpha2', 'RC1', etc. Maybe I missed a
> > page somewhere. Is there a preference/ mandate here?
> >
> >
> > Here are a few examples:
> >
> >
> >
> https://mail-archives.apache.org/mod_mbox/hadoop-yarn-dev/201509.mbox/%3ccalwht94xigohjrtimmqyx3gfodr2m8pyyp2fsnybrq6dat_...@mail.gmail.com%3E
> >
> > http://zookeeper.apache.org/doc/r3.5.1-alpha/
> >
> >
> >
> http://hadoop.apache.org/docs/r2.4.1/hadoop-project-dist/hadoop-common/releasenotes.html
> (search
> > for alpha, beta, etc)
> >
> >
> > If our versioning approach can be vetted, I agree with Anthony's
> > suggestion to have frequent releases scrubbing these issues - at least a
> > few at a time.
> >
> > Roman/ others: any guidance here?
> >
> > Thanks,
> > Nitin
> >
> > 
> > From: John Blum 
> > Sent: Monday, November 30, 2015 11:07 AM
> > To: dev@geode.incubator.apache.org
> > Subject: Re: Review of 1.0.0-alpha1 issues
> >
> > From my perspective, the (nearly) final, "releasable" POM is not needed
> > until we hit RC1.  By then, RCs should be relatively stable, having only
> > simple changes (e.g. bug fixes) until final GA.  Dependency additions,
> > exclusions should be worked out before/by RC1.
> >
> > On Mon, Nov 30, 2015 at 10:55 AM, Anthony Baker 
> wrote:
> >
> > Let’s get really specific when we talk about “release”.  GEODE-27 clearly
> > needs to be addressed prior to a 1.0.0 release.  Currently we are
> > discussing a 1.0.0-alpha1 release which will be followed soon after by
> > *-alpha2, *-alpha3, etc.
> >
> > Do we need GEODE-27 in 1.0.0-alpha1 or can it be deferred to a subsequent
> > alpha release?
> >
> > Anthony
> >
> >
> > On Nov 30, 2015, at 10:24 AM, William Markito 
> >
> > wrote:
> >
> >
> > Huge +1 for GEODE-27 before release.
> >
> > On Mon, Nov 30, 2015 at 9:13 AM, John Blum  wrote:
> >
> > Looking ahead, 1 issue, among others, that should warrant careful
> >
> > attention
> >
> > before the 1.0.0 RC, is GEODE-27
> >  [0].  Getting the POM
> > file
> > correct is not only important for Geode, but for developers building
> > applications

Re: Review Request 40784: GEODE-611: Change findbugs annotations to use ASL library

[Anthony Baker]

> On Dec. 1, 2015, midnight, Mark Bretl wrote:
> > Was 'findbugsMain' task run for testing?

Yes, I ran findbugsMain.  It generated a report of warnings, etc.


- Anthony


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


On Nov. 29, 2015, 4:28 p.m., Anthony Baker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/40784/
> ---
> 
> (Updated Nov. 29, 2015, 4:28 p.m.)
> 
> 
> Review request for geode, Mark Bretl and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Swtich the findbugs annotation dependency to use an ASL version
> from https://github.com/stephenc/findbugs-annotations.  This
> library only supports the SuppressWarning annotation, not
> SuppressFBWarning so some source files were updated.
> 
> 
> Diffs
> -
> 
>   build.gradle b5465b8eeb14408bae1624c8ffe7f25b4863e2b2 
>   gemfire-core/build.gradle dd3b765d31fac624d939045794bd77391a52bb6f 
>   gemfire-core/src/main/java/com/gemstone/gemfire/SystemFailure.java 
> 494f5f7ec3ddb33f2bf2abf202bc1d5c05ea668a 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/admin/jmx/internal/AgentImpl.java
>  4d1ad41c96772a4b40d7166422696cb2d7791ee1 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/admin/jmx/internal/GemFireHealthConfigJmxImpl.java
>  c05d4b8c69b7dd393efb8f91d290a48c0fe4fbbc 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/CompiledOperation.java
>  d9f0d6c53179068f02740f8d89c4c5b8f52e4b43 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/StatArchiveWriter.java
>  562cce34de85b6b4674457776e1427a61e37207b 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/AbstractUpdateOperation.java
>  3ac006b197fa1114713343b5a518929b40e6fe7b 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/TXStateProxyImpl.java
>  fda1a3ad58cb5bac228ceb1b9c3d72c2aaa70298 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/AcceptorImpl.java
>  89c073fd3bd366ba47f11dde56b034b8d92f57d0 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/BaseCommand.java
>  52ea6f55b55a656bdb02fb192c6d49ca309e07f8 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/ClientProxyMembershipID.java
>  daa07f482e9cf9b0d7ae0492e450d62795c62dec 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/versions/RegionVersionVector.java
>  61423d137b6788581001fe1f7bcc858f044bf33d 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/datasource/AbstractPoolCache.java
>  b615327971edbe51b232211ac57bf35dee4b51e0 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/memcached/commands/GetCommand.java
>  8fd08479ea4cda035fc41cfd10201b284eef5de3 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/statistics/SampleCollector.java
>  9b40e95b386370dd6b5e72a4bca956e6e97f3102 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/util/DebuggerSupport.java
>  49ce32e8dd92be2a34057969411eeb4acc6f95f3 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/util/SingletonValue.java
>  5f902b69576e14db8ceb5f05a52da2896968b0e7 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/util/concurrent/CustomEntryConcurrentHashMap.java
>  75dc330ea6ca38ccafc63328acc8c0693703bc47 
>   gradle/dependency-versions.properties 
> 3e6b6a511eac6992f2d0b114cc9c1ee002d7cce8 
> 
> Diff: https://reviews.apache.org/r/40784/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Anthony Baker
> 
>

Re: Review Request 40784: GEODE-611: Change findbugs annotations to use ASL library

[Mark Bretl]

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

Ship it!


Was 'findbugsMain' task run for testing?

- Mark Bretl


On Nov. 29, 2015, 4:28 p.m., Anthony Baker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/40784/
> ---
> 
> (Updated Nov. 29, 2015, 4:28 p.m.)
> 
> 
> Review request for geode, Mark Bretl and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Swtich the findbugs annotation dependency to use an ASL version
> from https://github.com/stephenc/findbugs-annotations.  This
> library only supports the SuppressWarning annotation, not
> SuppressFBWarning so some source files were updated.
> 
> 
> Diffs
> -
> 
>   build.gradle b5465b8eeb14408bae1624c8ffe7f25b4863e2b2 
>   gemfire-core/build.gradle dd3b765d31fac624d939045794bd77391a52bb6f 
>   gemfire-core/src/main/java/com/gemstone/gemfire/SystemFailure.java 
> 494f5f7ec3ddb33f2bf2abf202bc1d5c05ea668a 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/admin/jmx/internal/AgentImpl.java
>  4d1ad41c96772a4b40d7166422696cb2d7791ee1 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/admin/jmx/internal/GemFireHealthConfigJmxImpl.java
>  c05d4b8c69b7dd393efb8f91d290a48c0fe4fbbc 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/cache/query/internal/CompiledOperation.java
>  d9f0d6c53179068f02740f8d89c4c5b8f52e4b43 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/StatArchiveWriter.java
>  562cce34de85b6b4674457776e1427a61e37207b 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/AbstractUpdateOperation.java
>  3ac006b197fa1114713343b5a518929b40e6fe7b 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/TXStateProxyImpl.java
>  fda1a3ad58cb5bac228ceb1b9c3d72c2aaa70298 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/AcceptorImpl.java
>  89c073fd3bd366ba47f11dde56b034b8d92f57d0 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/BaseCommand.java
>  52ea6f55b55a656bdb02fb192c6d49ca309e07f8 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/ClientProxyMembershipID.java
>  daa07f482e9cf9b0d7ae0492e450d62795c62dec 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/versions/RegionVersionVector.java
>  61423d137b6788581001fe1f7bcc858f044bf33d 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/datasource/AbstractPoolCache.java
>  b615327971edbe51b232211ac57bf35dee4b51e0 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/memcached/commands/GetCommand.java
>  8fd08479ea4cda035fc41cfd10201b284eef5de3 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/statistics/SampleCollector.java
>  9b40e95b386370dd6b5e72a4bca956e6e97f3102 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/util/DebuggerSupport.java
>  49ce32e8dd92be2a34057969411eeb4acc6f95f3 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/util/SingletonValue.java
>  5f902b69576e14db8ceb5f05a52da2896968b0e7 
>   
> gemfire-core/src/main/java/com/gemstone/gemfire/internal/util/concurrent/CustomEntryConcurrentHashMap.java
>  75dc330ea6ca38ccafc63328acc8c0693703bc47 
>   gradle/dependency-versions.properties 
> 3e6b6a511eac6992f2d0b114cc9c1ee002d7cce8 
> 
> Diff: https://reviews.apache.org/r/40784/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Anthony Baker
> 
>

Re: Geode 1.0.0 (alpha1): Open questions

[Niall Pemberton]

On Mon, Nov 30, 2015 at 7:36 PM, Nitin Lamba  wrote:

> Wanted to start a thread capturing all the open (mostly process) questions
> for the first alpha1 release:
>
>
> - Does ASF have Pivotal's (or EMC's, VMware's, Gemstone's) CCLA on file?
> Who can confirm? This is a legal requirement
>

The only legal requirements are for a Software Grant for the original
donation and for ICLA's (Individual Contributor License Agreement) for each
committer - which you dont get an apache account without. Having said that
it is preferable[1] to have a CCLA and the ASF Secretary recorded a
CCLA from Pivotal on 7th May 2015 which listed the people working on Geode.

[1] http://markmail.org/message/izn5ecnzk53sn7e6

Niall

- Is the alternate (podling) release process<
> http://incubator.apache.org/guides/release.html#manifest-usage> available
> to Geode? Doesn't look like a popular method but may have advantages to
> partially automate the release manifest through the existing build process
>
>
> - What target build platforms (OS, etc) should be included in this
> release? Echoing the same question that was asked by Karen Miller regarding
> installation documents
>
>
> Please add other items, as appropriate.
>
>
> Thanks,
>
> Nitin
>
>
> 
>
>

Re: Review of 1.0.0-alpha1 issues

[Michael Stolz]

I would like to see one alpha. I don't think we're sure how solid some of
this stuff is.

"Testing cannot prove the absence of bugs...only the presence."

--
Mike Stolz
Principal Engineer - Gemfire Product Manager
Mobile: 631-835-4771
On Nov 30, 2015 4:28 PM, "Nitin Lamba"  wrote:

> Thanks Anil,
>
> From the best practices section:
>
> "TODO: (move to a note) Notes on 0.x releases verses alpha and betas. It
> is better to use 0.x releases than to create numerous alphas and betas for
> 1.0. Conventionally, 0.x releases are aimed at early adopters only without
> a strong promise of easy upgrade or backwards compatibility. 0.x is a good
> designation for a product that is not feature complete but whose code is
> solid for those features which are implemented. "
>
> My preference would be for dot releases instead of alpha1, apha2, beta,
> RC, etc. Other thoughts?
>
> As for the release tasks, perhaps you missed the Wiki page:
>
> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-alpha1+%28First%29+Release
>
> The JIRA (Agile) Board is here:
>
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=92&view=planning
>
> Was hoping to get more discussion/ feedback from the community on the Wiki
> before JIRA versions and tasks are created. Please review/ comment the
> contents, if not done already.
>
> Thanks,
> -Nitin
> 
> From: Anilkumar Gingade 
> Sent: Monday, November 30, 2015 2:47 PM
> To: dev@geode.incubator.apache.org
> Subject: Re: Review of 1.0.0-alpha1 issues
>
> Here is more detail on versioning
>
>
> http://incubator.apache.org/guides/releasemanagement.html#best-practice-naming
>  (under versioning section)
>
> Can we set a release task list...
> E.g.: What tasks/items are expected to complete to do an alpha, beta and
> final 1.0 release...
>
> -Anil.
>
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Nov 30, 2015 at 1:33 PM, Anthony Baker  wrote:
>
> >
> > On Nov 30, 2015, at 11:23 AM, Nitin Lamba  wrote:
> >
> > +1
> >
> > I do have a fundamental question about versioning (rather what versions
> > can be taken for voting/ approvals):
> >
> > Can an 'alpha' which has known issues (like GEODE-27 or GEODE-386 for
> > apache namespace, etc) be taken all the way through the PMC process for
> > approvals? Such a release will have to be posted to maven/ apache builds
> > but does it meet the quality requirements for an 'Apache Release’?
> >
> >
> > Good question.  I was assuming we would need to address GEODE-386 before
> > graduation but not for the first release.
> >
> >
> > Also, in the guidelines, I've seen references to dot releases 0.x.y up to
> > the 1.0 release but not 'alpha1', 'alpha2', 'RC1', etc. Maybe I missed a
> > page somewhere. Is there a preference/ mandate here?
> >
> >
> > Here are a few examples:
> >
> >
> >
> https://mail-archives.apache.org/mod_mbox/hadoop-yarn-dev/201509.mbox/%3ccalwht94xigohjrtimmqyx3gfodr2m8pyyp2fsnybrq6dat_...@mail.gmail.com%3E
> >
> > http://zookeeper.apache.org/doc/r3.5.1-alpha/
> >
> >
> >
> http://hadoop.apache.org/docs/r2.4.1/hadoop-project-dist/hadoop-common/releasenotes.html
> (search
> > for alpha, beta, etc)
> >
> >
> > If our versioning approach can be vetted, I agree with Anthony's
> > suggestion to have frequent releases scrubbing these issues - at least a
> > few at a time.
> >
> > Roman/ others: any guidance here?
> >
> > Thanks,
> > Nitin
> >
> > 
> > From: John Blum 
> > Sent: Monday, November 30, 2015 11:07 AM
> > To: dev@geode.incubator.apache.org
> > Subject: Re: Review of 1.0.0-alpha1 issues
> >
> > From my perspective, the (nearly) final, "releasable" POM is not needed
> > until we hit RC1.  By then, RCs should be relatively stable, having only
> > simple changes (e.g. bug fixes) until final GA.  Dependency additions,
> > exclusions should be worked out before/by RC1.
> >
> > On Mon, Nov 30, 2015 at 10:55 AM, Anthony Baker 
> wrote:
> >
> > Let’s get really specific when we talk about “release”.  GEODE-27 clearly
> > needs to be addressed prior to a 1.0.0 release.  Currently we are
> > discussing a 1.0.0-alpha1 release which will be followed soon after by
> > *-alpha2, *-alpha3, etc.
> >
> > Do we need GEODE-27 in 1.0.0-alpha1 or can it be deferred to a subsequent
> > alpha release?
> >
> > Anthony
> >
> >
> > On Nov 30, 2015, at 10:24 AM, William Markito 
> >
> > wrote:
> >
> >
> > Huge +1 for GEODE-27 before release.
> >
> > On Mon, Nov 30, 2015 at 9:13 AM, John Blum  wrote:
> >
> > Looking ahead, 1 issue, among others, that should warrant careful
> >
> > attention
> >
> > before the 1.0.0 RC, is GEODE-27
> >  [0].  Getting the POM
> > file
> > correct is not only important for Geode, but for developers building
> > applications using Geode.  Changing a POM file after a release is always
> > messy and not recommended since most artifact servers (e.g.
> >
> > Artifactory),
> >
> > and even local Maven repos, ca

Re: Review of 1.0.0-alpha1 issues

[Nitin Lamba]

Thanks Anil,

>From the best practices section:

"TODO: (move to a note) Notes on 0.x releases verses alpha and betas. It is 
better to use 0.x releases than to create numerous alphas and betas for 1.0. 
Conventionally, 0.x releases are aimed at early adopters only without a strong 
promise of easy upgrade or backwards compatibility. 0.x is a good designation 
for a product that is not feature complete but whose code is solid for those 
features which are implemented. "

My preference would be for dot releases instead of alpha1, apha2, beta, RC, 
etc. Other thoughts?

As for the release tasks, perhaps you missed the Wiki page:
https://cwiki.apache.org/confluence/display/GEODE/1.0.0-alpha1+%28First%29+Release

The JIRA (Agile) Board is here:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=92&view=planning

Was hoping to get more discussion/ feedback from the community on the Wiki 
before JIRA versions and tasks are created. Please review/ comment the 
contents, if not done already.

Thanks,
-Nitin

From: Anilkumar Gingade 
Sent: Monday, November 30, 2015 2:47 PM
To: dev@geode.incubator.apache.org
Subject: Re: Review of 1.0.0-alpha1 issues

Here is more detail on versioning

http://incubator.apache.org/guides/releasemanagement.html#best-practice-naming
 (under versioning section)

Can we set a release task list...
E.g.: What tasks/items are expected to complete to do an alpha, beta and
final 1.0 release...

-Anil.












On Mon, Nov 30, 2015 at 1:33 PM, Anthony Baker  wrote:

>
> On Nov 30, 2015, at 11:23 AM, Nitin Lamba  wrote:
>
> +1
>
> I do have a fundamental question about versioning (rather what versions
> can be taken for voting/ approvals):
>
> Can an 'alpha' which has known issues (like GEODE-27 or GEODE-386 for
> apache namespace, etc) be taken all the way through the PMC process for
> approvals? Such a release will have to be posted to maven/ apache builds
> but does it meet the quality requirements for an 'Apache Release’?
>
>
> Good question.  I was assuming we would need to address GEODE-386 before
> graduation but not for the first release.
>
>
> Also, in the guidelines, I've seen references to dot releases 0.x.y up to
> the 1.0 release but not 'alpha1', 'alpha2', 'RC1', etc. Maybe I missed a
> page somewhere. Is there a preference/ mandate here?
>
>
> Here are a few examples:
>
>
> https://mail-archives.apache.org/mod_mbox/hadoop-yarn-dev/201509.mbox/%3ccalwht94xigohjrtimmqyx3gfodr2m8pyyp2fsnybrq6dat_...@mail.gmail.com%3E
>
> http://zookeeper.apache.org/doc/r3.5.1-alpha/
>
>
> http://hadoop.apache.org/docs/r2.4.1/hadoop-project-dist/hadoop-common/releasenotes.html
>  (search
> for alpha, beta, etc)
>
>
> If our versioning approach can be vetted, I agree with Anthony's
> suggestion to have frequent releases scrubbing these issues - at least a
> few at a time.
>
> Roman/ others: any guidance here?
>
> Thanks,
> Nitin
>
> 
> From: John Blum 
> Sent: Monday, November 30, 2015 11:07 AM
> To: dev@geode.incubator.apache.org
> Subject: Re: Review of 1.0.0-alpha1 issues
>
> From my perspective, the (nearly) final, "releasable" POM is not needed
> until we hit RC1.  By then, RCs should be relatively stable, having only
> simple changes (e.g. bug fixes) until final GA.  Dependency additions,
> exclusions should be worked out before/by RC1.
>
> On Mon, Nov 30, 2015 at 10:55 AM, Anthony Baker  wrote:
>
> Let’s get really specific when we talk about “release”.  GEODE-27 clearly
> needs to be addressed prior to a 1.0.0 release.  Currently we are
> discussing a 1.0.0-alpha1 release which will be followed soon after by
> *-alpha2, *-alpha3, etc.
>
> Do we need GEODE-27 in 1.0.0-alpha1 or can it be deferred to a subsequent
> alpha release?
>
> Anthony
>
>
> On Nov 30, 2015, at 10:24 AM, William Markito 
>
> wrote:
>
>
> Huge +1 for GEODE-27 before release.
>
> On Mon, Nov 30, 2015 at 9:13 AM, John Blum  wrote:
>
> Looking ahead, 1 issue, among others, that should warrant careful
>
> attention
>
> before the 1.0.0 RC, is GEODE-27
>  [0].  Getting the POM
> file
> correct is not only important for Geode, but for developers building
> applications using Geode.  Changing a POM file after a release is always
> messy and not recommended since most artifact servers (e.g.
>
> Artifactory),
>
> and even local Maven repos, cache the POM file for a given version.  The
> only time it is ever appropriate to change a POM file is during a
>
> release
>
> of a *new* version (and typically non-GA/maintenance versions; i.e. when
> going from RC -> GA, the POM should remain fixed until the next
>
> major.minor
>
> version, e.g. 1.0 -> 1.1).  The unfortunate, but necessary, GemFire 8.1
>
> POM
>
> file change caused issues for developers recently; those developers were
> consuming GemFire indirectly.
>
> Thanks,
> -John
>
> [0] - https://issues.apache.org/jira/browse/GEODE-27
>
>

Re: Topic for Dec 17 Geode Clubhouse - what's coming in Apache Geode 1.0 Alpha?

[Gregory Chase]

+ William,

We want to get the topic for the next Geode Clubhouse user education locked
down for the 12/17 9AM Pacific time.

We had discussed an overview of what's coming in Apache Geode 1.0 Alpha.

There was also off channel talk about maybe doing a deep dive on the off
heap storage feature.

Do we feel ready to discuss the overall new version?

Or should we cue up the Offheap Memory discussion.

@William -> who did you say could speak about the Offheap Memory feature?

Thanks,

-Greg

On Fri, Nov 20, 2015 at 8:59 PM, Nitin Lamba  wrote:

> Hi Greg,
>
>
> Thanks for your note. I do get e-mails from dev@geode... :)
>
>
> The round table idea sounds great, however, before the Clubhouse which
> is ~4 weeks away, we should probably have trial-run (alpha) release prep as
> Anthony had suggested. This way, we can have a more focused discussion in
> the proposed roundtable.
>
>
> If you recall, we had good exchange on Geode 1.0.0 release and following
> was recommended:
>
> - Do a trial run with just GEODE-18
>  (license) and GEODE-77
>  (JGroups)
>
> - Go-through all the steps/ checks as part of the release process, etc
>
>
> Accordingly, I've updated the Wiki pages (reading recommended in the same
> order):
>
>
> - Release Management
> 
> (landing page)
>
> - Release Process
> 
> (2nd draft) - this is a long one!
>
> - 1.0.0 Release
> 
> (2nd draft)
>
>
> Comments are welcome. Meanwhile, I'll start a few separate threads for
> open questions I encountered.
>
>
> Have a good weekend!
>
> Nitin
>
>
> --
> *From:* Gregory Chase 
> *Sent:* Friday, November 20, 2015 2:40 PM
> *To:* Michael Stolz; Nitin Lamba
> *Cc:* Dormain Drewitz; dev@geode.incubator.apache.org
> *Subject:* Re: Topic for Dec 17 Geode Clubhouse - what's coming in Apache
> Geode 1.0 Alpha?
>
> Resending with Nitin's correct email address :)
>
> On Fri, Nov 20, 2015 at 2:23 PM, Gregory Chase  wrote:
>
>> Greetings Geode community,
>> We need a topic for the Dec 17 User education meeting.
>>
>> It seems to me that an extended discussion of what's coming in the Apache
>> Geode 1.0 Alpha would be a good way to go.
>>
>> I would recommend that Mike Stolz and Nitin lead a round table discussion.
>>
>> We could start with a grouping of Jira issues likely to be resolved and
>> included in the first alpha release. Each lead developer of each feature
>> group will develop a single slide and explain what's new or changed:
>>
>>
>> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=92&view=planning
>>
>> This will also be good for helping us create initial release
>> documentation.
>>
>> Sound ok?
>>
>> --
>> Greg Chase
>>
>> Director of Big Data Communities
>> http://www.pivotal.io/big-data
>>
>> Pivotal Software
>> http://www.pivotal.io/
>>
>> 650-215-0477
>> @GregChase
>> Blog: http://geekmarketing.biz/
>>
>>
>
>
> --
> Greg Chase
>
> Director of Big Data Communities
> http://www.pivotal.io/big-data
>
> Pivotal Software
> http://www.pivotal.io/
>
> 650-215-0477
> @GregChase
> Blog: http://geekmarketing.biz/
>
>


-- 
Greg Chase

Director of Big Data Communities
http://www.pivotal.io/big-data

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

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

Re: Review of 1.0.0-alpha1 issues

[Anilkumar Gingade]

Here is more detail on versioning

http://incubator.apache.org/guides/releasemanagement.html#best-practice-naming
 (under versioning section)

Can we set a release task list...
E.g.: What tasks/items are expected to complete to do an alpha, beta and
final 1.0 release...

-Anil.












On Mon, Nov 30, 2015 at 1:33 PM, Anthony Baker  wrote:

>
> On Nov 30, 2015, at 11:23 AM, Nitin Lamba  wrote:
>
> +1
>
> I do have a fundamental question about versioning (rather what versions
> can be taken for voting/ approvals):
>
> Can an 'alpha' which has known issues (like GEODE-27 or GEODE-386 for
> apache namespace, etc) be taken all the way through the PMC process for
> approvals? Such a release will have to be posted to maven/ apache builds
> but does it meet the quality requirements for an 'Apache Release’?
>
>
> Good question.  I was assuming we would need to address GEODE-386 before
> graduation but not for the first release.
>
>
> Also, in the guidelines, I've seen references to dot releases 0.x.y up to
> the 1.0 release but not 'alpha1', 'alpha2', 'RC1', etc. Maybe I missed a
> page somewhere. Is there a preference/ mandate here?
>
>
> Here are a few examples:
>
>
> https://mail-archives.apache.org/mod_mbox/hadoop-yarn-dev/201509.mbox/%3ccalwht94xigohjrtimmqyx3gfodr2m8pyyp2fsnybrq6dat_...@mail.gmail.com%3E
>
> http://zookeeper.apache.org/doc/r3.5.1-alpha/
>
>
> http://hadoop.apache.org/docs/r2.4.1/hadoop-project-dist/hadoop-common/releasenotes.html
>  (search
> for alpha, beta, etc)
>
>
> If our versioning approach can be vetted, I agree with Anthony's
> suggestion to have frequent releases scrubbing these issues - at least a
> few at a time.
>
> Roman/ others: any guidance here?
>
> Thanks,
> Nitin
>
> 
> From: John Blum 
> Sent: Monday, November 30, 2015 11:07 AM
> To: dev@geode.incubator.apache.org
> Subject: Re: Review of 1.0.0-alpha1 issues
>
> From my perspective, the (nearly) final, "releasable" POM is not needed
> until we hit RC1.  By then, RCs should be relatively stable, having only
> simple changes (e.g. bug fixes) until final GA.  Dependency additions,
> exclusions should be worked out before/by RC1.
>
> On Mon, Nov 30, 2015 at 10:55 AM, Anthony Baker  wrote:
>
> Let’s get really specific when we talk about “release”.  GEODE-27 clearly
> needs to be addressed prior to a 1.0.0 release.  Currently we are
> discussing a 1.0.0-alpha1 release which will be followed soon after by
> *-alpha2, *-alpha3, etc.
>
> Do we need GEODE-27 in 1.0.0-alpha1 or can it be deferred to a subsequent
> alpha release?
>
> Anthony
>
>
> On Nov 30, 2015, at 10:24 AM, William Markito 
>
> wrote:
>
>
> Huge +1 for GEODE-27 before release.
>
> On Mon, Nov 30, 2015 at 9:13 AM, John Blum  wrote:
>
> Looking ahead, 1 issue, among others, that should warrant careful
>
> attention
>
> before the 1.0.0 RC, is GEODE-27
>  [0].  Getting the POM
> file
> correct is not only important for Geode, but for developers building
> applications using Geode.  Changing a POM file after a release is always
> messy and not recommended since most artifact servers (e.g.
>
> Artifactory),
>
> and even local Maven repos, cache the POM file for a given version.  The
> only time it is ever appropriate to change a POM file is during a
>
> release
>
> of a *new* version (and typically non-GA/maintenance versions; i.e. when
> going from RC -> GA, the POM should remain fixed until the next
>
> major.minor
>
> version, e.g. 1.0 -> 1.1).  The unfortunate, but necessary, GemFire 8.1
>
> POM
>
> file change caused issues for developers recently; those developers were
> consuming GemFire indirectly.
>
> Thanks,
> -John
>
> [0] - https://issues.apache.org/jira/browse/GEODE-27
>
>
> On Sun, Nov 29, 2015 at 7:40 AM, Anthony Baker 
>
> wrote:
>
>
> ICYMI, Nitin created a sprint dashboard for the 1.0.0-alpha1 release
>
> [1].
>
> I’ve added a few issues to it based on the licensing reviews Niall and
>
> Dick
>
> are doing.  Here’s the summary:
>
> *** GEODE-32 / wiki page to document release process [2]
>
> Looks pretty good good.  There are a few inline question marks to fill
>
> out.
>
>
> *** GEODE-18 / source file headers
> *** GEODE-608 / Integrate RAT into build
> I’ve added build support for RAT on the feature/GEODE-608 branch.  This
> should make closing out GEODE-18 easier.  The excludes file is based on
>
> the
>
> one attached to GEODE-18.  There are a few more files to evaluate and
>
> the
>
> entire excludes list should be reviewed for correctness.
>
> *** GEODE-610 / Review LICENSE and NOTICE
>
> Niall exported the source and dependent licenses that need to be fed
>
> into
>
> edits on the LICENSE and NOTICE files.
>
> *** GEODE-611 / Replace Findbugs annotations
>
> We can replace the LGPL-licensed findbugs annotation library with an
>
> ASL
>
> clean implementation.
>
>
> Anthony
>
>
> [1]
>
>
>
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidV

Can we close done Reviews on ReviewBoard ?

[William Markito]

That would be really nice so we can have a better picture/metric about
what's pending review vs what's still really open there.

I'm going to start that by closing the ones that are older than 1 month
(with no updates)

Please let me know if you think otherwise.
-- 

William Markito Oliveira
-- For questions about Apache Geode, please write to
*dev@geode.incubator.apache.org
*

Re: Review of 1.0.0-alpha1 issues

[Anthony Baker]

> On Nov 30, 2015, at 11:23 AM, Nitin Lamba  wrote:
> 
> +1
> 
> I do have a fundamental question about versioning (rather what versions can 
> be taken for voting/ approvals):
> 
> Can an 'alpha' which has known issues (like GEODE-27 or GEODE-386 for apache 
> namespace, etc) be taken all the way through the PMC process for approvals? 
> Such a release will have to be posted to maven/ apache builds but does it 
> meet the quality requirements for an 'Apache Release’?

Good question.  I was assuming we would need to address GEODE-386 before 
graduation but not for the first release.

> 
> Also, in the guidelines, I've seen references to dot releases 0.x.y up to the 
> 1.0 release but not 'alpha1', 'alpha2', 'RC1', etc. Maybe I missed a page 
> somewhere. Is there a preference/ mandate here?
> 

Here are a few examples:

https://mail-archives.apache.org/mod_mbox/hadoop-yarn-dev/201509.mbox/%3ccalwht94xigohjrtimmqyx3gfodr2m8pyyp2fsnybrq6dat_...@mail.gmail.com%3E
 


http://zookeeper.apache.org/doc/r3.5.1-alpha/ 


http://hadoop.apache.org/docs/r2.4.1/hadoop-project-dist/hadoop-common/releasenotes.html
 

 (search for alpha, beta, etc)


> If our versioning approach can be vetted, I agree with Anthony's suggestion 
> to have frequent releases scrubbing these issues - at least a few at a time.
> 
> Roman/ others: any guidance here?
> 
> Thanks,
> Nitin
> 
> 
> From: John Blum 
> Sent: Monday, November 30, 2015 11:07 AM
> To: dev@geode.incubator.apache.org
> Subject: Re: Review of 1.0.0-alpha1 issues
> 
> From my perspective, the (nearly) final, "releasable" POM is not needed
> until we hit RC1.  By then, RCs should be relatively stable, having only
> simple changes (e.g. bug fixes) until final GA.  Dependency additions,
> exclusions should be worked out before/by RC1.
> 
> On Mon, Nov 30, 2015 at 10:55 AM, Anthony Baker  wrote:
> 
>> Let’s get really specific when we talk about “release”.  GEODE-27 clearly
>> needs to be addressed prior to a 1.0.0 release.  Currently we are
>> discussing a 1.0.0-alpha1 release which will be followed soon after by
>> *-alpha2, *-alpha3, etc.
>> 
>> Do we need GEODE-27 in 1.0.0-alpha1 or can it be deferred to a subsequent
>> alpha release?
>> 
>> Anthony
>> 
>> 
>>> On Nov 30, 2015, at 10:24 AM, William Markito 
>> wrote:
>>> 
>>> Huge +1 for GEODE-27 before release.
>>> 
>>> On Mon, Nov 30, 2015 at 9:13 AM, John Blum  wrote:
>>> 
 Looking ahead, 1 issue, among others, that should warrant careful
>> attention
 before the 1.0.0 RC, is GEODE-27
  [0].  Getting the POM
 file
 correct is not only important for Geode, but for developers building
 applications using Geode.  Changing a POM file after a release is always
 messy and not recommended since most artifact servers (e.g.
>> Artifactory),
 and even local Maven repos, cache the POM file for a given version.  The
 only time it is ever appropriate to change a POM file is during a
>> release
 of a *new* version (and typically non-GA/maintenance versions; i.e. when
 going from RC -> GA, the POM should remain fixed until the next
>> major.minor
 version, e.g. 1.0 -> 1.1).  The unfortunate, but necessary, GemFire 8.1
>> POM
 file change caused issues for developers recently; those developers were
 consuming GemFire indirectly.
 
 Thanks,
 -John
 
 [0] - https://issues.apache.org/jira/browse/GEODE-27
 
 
 On Sun, Nov 29, 2015 at 7:40 AM, Anthony Baker 
>> wrote:
 
> ICYMI, Nitin created a sprint dashboard for the 1.0.0-alpha1 release
>> [1].
> I’ve added a few issues to it based on the licensing reviews Niall and
 Dick
> are doing.  Here’s the summary:
> 
> *** GEODE-32 / wiki page to document release process [2]
> 
> Looks pretty good good.  There are a few inline question marks to fill
 out.
> 
> *** GEODE-18 / source file headers
> *** GEODE-608 / Integrate RAT into build
> I’ve added build support for RAT on the feature/GEODE-608 branch.  This
> should make closing out GEODE-18 easier.  The excludes file is based on
 the
> one attached to GEODE-18.  There are a few more files to evaluate and
>> the
> entire excludes list should be reviewed for correctness.
> 
> *** GEODE-610 / Review LICENSE and NOTICE
> 
> Niall exported the source and dependent licenses that need to be fed
>> into
> edits on the LICENSE and NOTICE files.
> 
> *** GEODE-611 / Replace Findbugs annotations
> 
> We can replace the LGPL-licensed findbugs annotation library with an
>> ASL
> clean implementatio

Geode 1.0.0 (alpha1): Open questions

[Nitin Lamba]

Wanted to start a thread capturing all the open (mostly process) questions for 
the first alpha1 release:


- Does ASF have Pivotal's (or EMC's, VMware's, Gemstone's) CCLA on file? Who 
can confirm? This is a legal requirement


- Is the alternate (podling) release 
process 
available to Geode? Doesn't look like a popular method but may have advantages 
to partially automate the release manifest through the existing build process


- What target build platforms (OS, etc) should be included in this release? 
Echoing the same question that was asked by Karen Miller regarding installation 
documents


Please add other items, as appropriate.


Thanks,

Nitin

Re: Review of 1.0.0-alpha1 issues

[Nitin Lamba]

+1

I do have a fundamental question about versioning (rather what versions can be 
taken for voting/ approvals):

Can an 'alpha' which has known issues (like GEODE-27 or GEODE-386 for apache 
namespace, etc) be taken all the way through the PMC process for approvals? 
Such a release will have to be posted to maven/ apache builds but does it meet 
the quality requirements for an 'Apache Release'?

Also, in the guidelines, I've seen references to dot releases 0.x.y up to the 
1.0 release but not 'alpha1', 'alpha2', 'RC1', etc. Maybe I missed a page 
somewhere. Is there a preference/ mandate here?

If our versioning approach can be vetted, I agree with Anthony's suggestion to 
have frequent releases scrubbing these issues - at least a few at a time.

Roman/ others: any guidance here?

Thanks,
Nitin


From: John Blum 
Sent: Monday, November 30, 2015 11:07 AM
To: dev@geode.incubator.apache.org
Subject: Re: Review of 1.0.0-alpha1 issues

>From my perspective, the (nearly) final, "releasable" POM is not needed
until we hit RC1.  By then, RCs should be relatively stable, having only
simple changes (e.g. bug fixes) until final GA.  Dependency additions,
exclusions should be worked out before/by RC1.

On Mon, Nov 30, 2015 at 10:55 AM, Anthony Baker  wrote:

> Let’s get really specific when we talk about “release”.  GEODE-27 clearly
> needs to be addressed prior to a 1.0.0 release.  Currently we are
> discussing a 1.0.0-alpha1 release which will be followed soon after by
> *-alpha2, *-alpha3, etc.
>
> Do we need GEODE-27 in 1.0.0-alpha1 or can it be deferred to a subsequent
> alpha release?
>
> Anthony
>
>
> > On Nov 30, 2015, at 10:24 AM, William Markito 
> wrote:
> >
> > Huge +1 for GEODE-27 before release.
> >
> > On Mon, Nov 30, 2015 at 9:13 AM, John Blum  wrote:
> >
> >> Looking ahead, 1 issue, among others, that should warrant careful
> attention
> >> before the 1.0.0 RC, is GEODE-27
> >>  [0].  Getting the POM
> >> file
> >> correct is not only important for Geode, but for developers building
> >> applications using Geode.  Changing a POM file after a release is always
> >> messy and not recommended since most artifact servers (e.g.
> Artifactory),
> >> and even local Maven repos, cache the POM file for a given version.  The
> >> only time it is ever appropriate to change a POM file is during a
> release
> >> of a *new* version (and typically non-GA/maintenance versions; i.e. when
> >> going from RC -> GA, the POM should remain fixed until the next
> major.minor
> >> version, e.g. 1.0 -> 1.1).  The unfortunate, but necessary, GemFire 8.1
> POM
> >> file change caused issues for developers recently; those developers were
> >> consuming GemFire indirectly.
> >>
> >> Thanks,
> >> -John
> >>
> >> [0] - https://issues.apache.org/jira/browse/GEODE-27
> >>
> >>
> >> On Sun, Nov 29, 2015 at 7:40 AM, Anthony Baker 
> wrote:
> >>
> >>> ICYMI, Nitin created a sprint dashboard for the 1.0.0-alpha1 release
> [1].
> >>> I’ve added a few issues to it based on the licensing reviews Niall and
> >> Dick
> >>> are doing.  Here’s the summary:
> >>>
> >>> *** GEODE-32 / wiki page to document release process [2]
> >>>
> >>> Looks pretty good good.  There are a few inline question marks to fill
> >> out.
> >>>
> >>> *** GEODE-18 / source file headers
> >>> *** GEODE-608 / Integrate RAT into build
> >>> I’ve added build support for RAT on the feature/GEODE-608 branch.  This
> >>> should make closing out GEODE-18 easier.  The excludes file is based on
> >> the
> >>> one attached to GEODE-18.  There are a few more files to evaluate and
> the
> >>> entire excludes list should be reviewed for correctness.
> >>>
> >>> *** GEODE-610 / Review LICENSE and NOTICE
> >>>
> >>> Niall exported the source and dependent licenses that need to be fed
> into
> >>> edits on the LICENSE and NOTICE files.
> >>>
> >>> *** GEODE-611 / Replace Findbugs annotations
> >>>
> >>> We can replace the LGPL-licensed findbugs annotation library with an
> ASL
> >>> clean implementation.
> >>>
> >>>
> >>> Anthony
> >>>
> >>>
> >>> [1]
> >>>
> >>
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=92&view=planning
> >>> [2]
> >>>
> >>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=57311453
> >>>
> >>>
> >>
> >>
> >> --
> >> -John
> >> 503-504-8657
> >> john.blum10101 (skype)
> >>
> >
> >
> >
> > --
> >
> > William Markito Oliveira
> > -- For questions about Apache Geode, please write to
> > *dev@geode.incubator.apache.org
> > *
>
>


--
-John
503-504-8657
john.blum10101 (skype)

Re: Review of 1.0.0-alpha1 issues

[John Blum]

>From my perspective, the (nearly) final, "releasable" POM is not needed
until we hit RC1.  By then, RCs should be relatively stable, having only
simple changes (e.g. bug fixes) until final GA.  Dependency additions,
exclusions should be worked out before/by RC1.

On Mon, Nov 30, 2015 at 10:55 AM, Anthony Baker  wrote:

> Let’s get really specific when we talk about “release”.  GEODE-27 clearly
> needs to be addressed prior to a 1.0.0 release.  Currently we are
> discussing a 1.0.0-alpha1 release which will be followed soon after by
> *-alpha2, *-alpha3, etc.
>
> Do we need GEODE-27 in 1.0.0-alpha1 or can it be deferred to a subsequent
> alpha release?
>
> Anthony
>
>
> > On Nov 30, 2015, at 10:24 AM, William Markito 
> wrote:
> >
> > Huge +1 for GEODE-27 before release.
> >
> > On Mon, Nov 30, 2015 at 9:13 AM, John Blum  wrote:
> >
> >> Looking ahead, 1 issue, among others, that should warrant careful
> attention
> >> before the 1.0.0 RC, is GEODE-27
> >>  [0].  Getting the POM
> >> file
> >> correct is not only important for Geode, but for developers building
> >> applications using Geode.  Changing a POM file after a release is always
> >> messy and not recommended since most artifact servers (e.g.
> Artifactory),
> >> and even local Maven repos, cache the POM file for a given version.  The
> >> only time it is ever appropriate to change a POM file is during a
> release
> >> of a *new* version (and typically non-GA/maintenance versions; i.e. when
> >> going from RC -> GA, the POM should remain fixed until the next
> major.minor
> >> version, e.g. 1.0 -> 1.1).  The unfortunate, but necessary, GemFire 8.1
> POM
> >> file change caused issues for developers recently; those developers were
> >> consuming GemFire indirectly.
> >>
> >> Thanks,
> >> -John
> >>
> >> [0] - https://issues.apache.org/jira/browse/GEODE-27
> >>
> >>
> >> On Sun, Nov 29, 2015 at 7:40 AM, Anthony Baker 
> wrote:
> >>
> >>> ICYMI, Nitin created a sprint dashboard for the 1.0.0-alpha1 release
> [1].
> >>> I’ve added a few issues to it based on the licensing reviews Niall and
> >> Dick
> >>> are doing.  Here’s the summary:
> >>>
> >>> *** GEODE-32 / wiki page to document release process [2]
> >>>
> >>> Looks pretty good good.  There are a few inline question marks to fill
> >> out.
> >>>
> >>> *** GEODE-18 / source file headers
> >>> *** GEODE-608 / Integrate RAT into build
> >>> I’ve added build support for RAT on the feature/GEODE-608 branch.  This
> >>> should make closing out GEODE-18 easier.  The excludes file is based on
> >> the
> >>> one attached to GEODE-18.  There are a few more files to evaluate and
> the
> >>> entire excludes list should be reviewed for correctness.
> >>>
> >>> *** GEODE-610 / Review LICENSE and NOTICE
> >>>
> >>> Niall exported the source and dependent licenses that need to be fed
> into
> >>> edits on the LICENSE and NOTICE files.
> >>>
> >>> *** GEODE-611 / Replace Findbugs annotations
> >>>
> >>> We can replace the LGPL-licensed findbugs annotation library with an
> ASL
> >>> clean implementation.
> >>>
> >>>
> >>> Anthony
> >>>
> >>>
> >>> [1]
> >>>
> >>
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=92&view=planning
> >>> [2]
> >>>
> >>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=57311453
> >>>
> >>>
> >>
> >>
> >> --
> >> -John
> >> 503-504-8657
> >> john.blum10101 (skype)
> >>
> >
> >
> >
> > --
> >
> > William Markito Oliveira
> > -- For questions about Apache Geode, please write to
> > *dev@geode.incubator.apache.org
> > *
>
>


-- 
-John
503-504-8657
john.blum10101 (skype)

Re: Review of 1.0.0-alpha1 issues

[Anthony Baker]

Let’s get really specific when we talk about “release”.  GEODE-27 clearly needs 
to be addressed prior to a 1.0.0 release.  Currently we are discussing a 
1.0.0-alpha1 release which will be followed soon after by *-alpha2, *-alpha3, 
etc.

Do we need GEODE-27 in 1.0.0-alpha1 or can it be deferred to a subsequent alpha 
release?

Anthony


> On Nov 30, 2015, at 10:24 AM, William Markito  wrote:
> 
> Huge +1 for GEODE-27 before release.
> 
> On Mon, Nov 30, 2015 at 9:13 AM, John Blum  wrote:
> 
>> Looking ahead, 1 issue, among others, that should warrant careful attention
>> before the 1.0.0 RC, is GEODE-27
>>  [0].  Getting the POM
>> file
>> correct is not only important for Geode, but for developers building
>> applications using Geode.  Changing a POM file after a release is always
>> messy and not recommended since most artifact servers (e.g. Artifactory),
>> and even local Maven repos, cache the POM file for a given version.  The
>> only time it is ever appropriate to change a POM file is during a release
>> of a *new* version (and typically non-GA/maintenance versions; i.e. when
>> going from RC -> GA, the POM should remain fixed until the next major.minor
>> version, e.g. 1.0 -> 1.1).  The unfortunate, but necessary, GemFire 8.1 POM
>> file change caused issues for developers recently; those developers were
>> consuming GemFire indirectly.
>> 
>> Thanks,
>> -John
>> 
>> [0] - https://issues.apache.org/jira/browse/GEODE-27
>> 
>> 
>> On Sun, Nov 29, 2015 at 7:40 AM, Anthony Baker  wrote:
>> 
>>> ICYMI, Nitin created a sprint dashboard for the 1.0.0-alpha1 release [1].
>>> I’ve added a few issues to it based on the licensing reviews Niall and
>> Dick
>>> are doing.  Here’s the summary:
>>> 
>>> *** GEODE-32 / wiki page to document release process [2]
>>> 
>>> Looks pretty good good.  There are a few inline question marks to fill
>> out.
>>> 
>>> *** GEODE-18 / source file headers
>>> *** GEODE-608 / Integrate RAT into build
>>> I’ve added build support for RAT on the feature/GEODE-608 branch.  This
>>> should make closing out GEODE-18 easier.  The excludes file is based on
>> the
>>> one attached to GEODE-18.  There are a few more files to evaluate and the
>>> entire excludes list should be reviewed for correctness.
>>> 
>>> *** GEODE-610 / Review LICENSE and NOTICE
>>> 
>>> Niall exported the source and dependent licenses that need to be fed into
>>> edits on the LICENSE and NOTICE files.
>>> 
>>> *** GEODE-611 / Replace Findbugs annotations
>>> 
>>> We can replace the LGPL-licensed findbugs annotation library with an ASL
>>> clean implementation.
>>> 
>>> 
>>> Anthony
>>> 
>>> 
>>> [1]
>>> 
>> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=92&view=planning
>>> [2]
>>> 
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=57311453
>>> 
>>> 
>> 
>> 
>> --
>> -John
>> 503-504-8657
>> john.blum10101 (skype)
>> 
> 
> 
> 
> --
> 
> William Markito Oliveira
> -- For questions about Apache Geode, please write to
> *dev@geode.incubator.apache.org
> *



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Final updates to Geode Website - Ready ?

[John Blum]

+1

On Mon, Nov 30, 2015 at 10:48 AM, Anthony Baker  wrote:

> Thanks William.  Can we postpone moving the docs hosting site until after
> the website refresh?  Seems like there is some good work here that would be
> nice to see published ASAP.
>
> Anthony
>
>
> > On Nov 30, 2015, at 10:27 AM, William Markito 
> wrote:
> >
> > Thank you very much for the awesome feedback Niall! Will try to get an
> > updated version up again soon.
> >
> > The only issue of the list that I can't really fix myself but that we
> > should discuss is around moving the docs from
> http://geode.docs.pivotal.io
> >
> > On Thu, Nov 26, 2015 at 2:06 PM, Niall Pemberton <
> niall.pember...@gmail.com>
> > wrote:
> >
> >> Firstly, the new website looks great.
> >>
> >> I have the following comments
> >>
> >> 1. Website Policy
> >> Please review the ASF Website Policy[1]. I did a quick scan and noticed
> two
> >> things:
> >>  * Need to include a prominent link to the main http://www.apache.org
> [2]
> >>  * The links/logos to IntelliJ & YourKit need to be removed until
> >> trademarks@ has been consulted as per the policy[2]
> >>
> >> [1] http://www.apache.org/foundation/marks/pmcs.html
> >> [2] http://www.apache.org/foundation/marks/pmcs.html#navigation
> >>
> >> 2. Navigation Bar
> >> * IMO it would be better to have a link to the "Mailing Lists" section
> >> rather than StackOverflow on the navigation bar at the top of the page.
> >> * The Docs link directs to http://geode.docs.pivotal.io - this needs to
> >> be
> >> moved to the ASF.
> >>
> >> 3. Community / Mailing Lists
> >> IMO the mailing lists should be moved higher up the page (above the
> >> "Events" and "Live Chat and Geode Clubhouse" sections). The heart of any
> >> Apache community are the mailing lists and should be the easiest to
> find,
> >> rather than having to scroll down to see that section.
> >>
> >> Can you also link to markmail for mailing list archives as its a much
> >> better UI than the official one:
> >>  * http://geode.markmail.org/
> >>
> >> Niall
> >>
> >> On Wed, Nov 25, 2015 at 6:30 AM, William Markito 
> >> wrote:
> >>
> >>> I've just pushed the latest fixes and added content to the community
> page
> >>> as well.
> >>>
> >>> Please check the result here ->
> http://markito.github.io/geode-website/
> >>> (clear your cache)
> >>>
> >>> From my point of view and based on the feedback I got so far, this is
> >>> *ready* to be pushed to asf-site and update our current website.
> >>>
> >>> Please let me know if you think otherwise, have any comments or
> feedback.
> >>>
> >>> Thanks,
> >>> --
> >>>
> >>> William Markito Oliveira
> >>> -- For questions about Apache Geode, please write to
> >>> *dev@geode.incubator.apache.org
> >>> *
> >>>
> >>
> >
> >
> >
> > --
> >
> > William Markito Oliveira
> > -- For questions about Apache Geode, please write to
> > *dev@geode.incubator.apache.org
> > *
>
>


-- 
-John
503-504-8657
john.blum10101 (skype)

Re: Final updates to Geode Website - Ready ?

[Anthony Baker]

Thanks William.  Can we postpone moving the docs hosting site until after the 
website refresh?  Seems like there is some good work here that would be nice to 
see published ASAP.

Anthony


> On Nov 30, 2015, at 10:27 AM, William Markito  wrote:
> 
> Thank you very much for the awesome feedback Niall! Will try to get an
> updated version up again soon.
> 
> The only issue of the list that I can't really fix myself but that we
> should discuss is around moving the docs from http://geode.docs.pivotal.io
> 
> On Thu, Nov 26, 2015 at 2:06 PM, Niall Pemberton 
> wrote:
> 
>> Firstly, the new website looks great.
>> 
>> I have the following comments
>> 
>> 1. Website Policy
>> Please review the ASF Website Policy[1]. I did a quick scan and noticed two
>> things:
>>  * Need to include a prominent link to the main http://www.apache.org [2]
>>  * The links/logos to IntelliJ & YourKit need to be removed until
>> trademarks@ has been consulted as per the policy[2]
>> 
>> [1] http://www.apache.org/foundation/marks/pmcs.html
>> [2] http://www.apache.org/foundation/marks/pmcs.html#navigation
>> 
>> 2. Navigation Bar
>> * IMO it would be better to have a link to the "Mailing Lists" section
>> rather than StackOverflow on the navigation bar at the top of the page.
>> * The Docs link directs to http://geode.docs.pivotal.io - this needs to
>> be
>> moved to the ASF.
>> 
>> 3. Community / Mailing Lists
>> IMO the mailing lists should be moved higher up the page (above the
>> "Events" and "Live Chat and Geode Clubhouse" sections). The heart of any
>> Apache community are the mailing lists and should be the easiest to find,
>> rather than having to scroll down to see that section.
>> 
>> Can you also link to markmail for mailing list archives as its a much
>> better UI than the official one:
>>  * http://geode.markmail.org/
>> 
>> Niall
>> 
>> On Wed, Nov 25, 2015 at 6:30 AM, William Markito 
>> wrote:
>> 
>>> I've just pushed the latest fixes and added content to the community page
>>> as well.
>>> 
>>> Please check the result here -> http://markito.github.io/geode-website/
>>> (clear your cache)
>>> 
>>> From my point of view and based on the feedback I got so far, this is
>>> *ready* to be pushed to asf-site and update our current website.
>>> 
>>> Please let me know if you think otherwise, have any comments or feedback.
>>> 
>>> Thanks,
>>> --
>>> 
>>> William Markito Oliveira
>>> -- For questions about Apache Geode, please write to
>>> *dev@geode.incubator.apache.org
>>> *
>>> 
>> 
> 
> 
> 
> --
> 
> William Markito Oliveira
> -- For questions about Apache Geode, please write to
> *dev@geode.incubator.apache.org
> *



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Final updates to Geode Website - Ready ?

[William Markito]

Thank you very much for the awesome feedback Niall! Will try to get an
updated version up again soon.

The only issue of the list that I can't really fix myself but that we
should discuss is around moving the docs from http://geode.docs.pivotal.io

On Thu, Nov 26, 2015 at 2:06 PM, Niall Pemberton 
wrote:

> Firstly, the new website looks great.
>
> I have the following comments
>
> 1. Website Policy
> Please review the ASF Website Policy[1]. I did a quick scan and noticed two
> things:
>   * Need to include a prominent link to the main http://www.apache.org [2]
>   * The links/logos to IntelliJ & YourKit need to be removed until
> trademarks@ has been consulted as per the policy[2]
>
> [1] http://www.apache.org/foundation/marks/pmcs.html
> [2] http://www.apache.org/foundation/marks/pmcs.html#navigation
>
> 2. Navigation Bar
>  * IMO it would be better to have a link to the "Mailing Lists" section
> rather than StackOverflow on the navigation bar at the top of the page.
>  * The Docs link directs to http://geode.docs.pivotal.io - this needs to
> be
> moved to the ASF.
>
> 3. Community / Mailing Lists
> IMO the mailing lists should be moved higher up the page (above the
> "Events" and "Live Chat and Geode Clubhouse" sections). The heart of any
> Apache community are the mailing lists and should be the easiest to find,
> rather than having to scroll down to see that section.
>
> Can you also link to markmail for mailing list archives as its a much
> better UI than the official one:
>   * http://geode.markmail.org/
>
> Niall
>
> On Wed, Nov 25, 2015 at 6:30 AM, William Markito 
> wrote:
>
> > I've just pushed the latest fixes and added content to the community page
> > as well.
> >
> > Please check the result here -> http://markito.github.io/geode-website/
> > (clear your cache)
> >
> > From my point of view and based on the feedback I got so far, this is
> > *ready* to be pushed to asf-site and update our current website.
> >
> > Please let me know if you think otherwise, have any comments or feedback.
> >
> > Thanks,
> > --
> >
> > William Markito Oliveira
> > -- For questions about Apache Geode, please write to
> > *dev@geode.incubator.apache.org
> > *
> >
>



-- 

William Markito Oliveira
-- For questions about Apache Geode, please write to
*dev@geode.incubator.apache.org
*

Re: Review of 1.0.0-alpha1 issues

[William Markito]

Huge +1 for GEODE-27 before release.

On Mon, Nov 30, 2015 at 9:13 AM, John Blum  wrote:

> Looking ahead, 1 issue, among others, that should warrant careful attention
> before the 1.0.0 RC, is GEODE-27
>  [0].  Getting the POM
> file
> correct is not only important for Geode, but for developers building
> applications using Geode.  Changing a POM file after a release is always
> messy and not recommended since most artifact servers (e.g. Artifactory),
> and even local Maven repos, cache the POM file for a given version.  The
> only time it is ever appropriate to change a POM file is during a release
> of a *new* version (and typically non-GA/maintenance versions; i.e. when
> going from RC -> GA, the POM should remain fixed until the next major.minor
> version, e.g. 1.0 -> 1.1).  The unfortunate, but necessary, GemFire 8.1 POM
> file change caused issues for developers recently; those developers were
> consuming GemFire indirectly.
>
> Thanks,
> -John
>
> [0] - https://issues.apache.org/jira/browse/GEODE-27
>
>
> On Sun, Nov 29, 2015 at 7:40 AM, Anthony Baker  wrote:
>
> > ICYMI, Nitin created a sprint dashboard for the 1.0.0-alpha1 release [1].
> > I’ve added a few issues to it based on the licensing reviews Niall and
> Dick
> > are doing.  Here’s the summary:
> >
> > *** GEODE-32 / wiki page to document release process [2]
> >
> > Looks pretty good good.  There are a few inline question marks to fill
> out.
> >
> > *** GEODE-18 / source file headers
> > *** GEODE-608 / Integrate RAT into build
> > I’ve added build support for RAT on the feature/GEODE-608 branch.  This
> > should make closing out GEODE-18 easier.  The excludes file is based on
> the
> > one attached to GEODE-18.  There are a few more files to evaluate and the
> > entire excludes list should be reviewed for correctness.
> >
> > *** GEODE-610 / Review LICENSE and NOTICE
> >
> > Niall exported the source and dependent licenses that need to be fed into
> > edits on the LICENSE and NOTICE files.
> >
> > *** GEODE-611 / Replace Findbugs annotations
> >
> > We can replace the LGPL-licensed findbugs annotation library with an ASL
> > clean implementation.
> >
> >
> > Anthony
> >
> >
> > [1]
> >
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=92&view=planning
> > [2]
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=57311453
> >
> >
>
>
> --
> -John
> 503-504-8657
> john.blum10101 (skype)
>



-- 

William Markito Oliveira
-- For questions about Apache Geode, please write to
*dev@geode.incubator.apache.org
*

Re: Review of 1.0.0-alpha1 issues

[John Blum]

Looking ahead, 1 issue, among others, that should warrant careful attention
before the 1.0.0 RC, is GEODE-27
 [0].  Getting the POM file
correct is not only important for Geode, but for developers building
applications using Geode.  Changing a POM file after a release is always
messy and not recommended since most artifact servers (e.g. Artifactory),
and even local Maven repos, cache the POM file for a given version.  The
only time it is ever appropriate to change a POM file is during a release
of a *new* version (and typically non-GA/maintenance versions; i.e. when
going from RC -> GA, the POM should remain fixed until the next major.minor
version, e.g. 1.0 -> 1.1).  The unfortunate, but necessary, GemFire 8.1 POM
file change caused issues for developers recently; those developers were
consuming GemFire indirectly.

Thanks,
-John

[0] - https://issues.apache.org/jira/browse/GEODE-27


On Sun, Nov 29, 2015 at 7:40 AM, Anthony Baker  wrote:

> ICYMI, Nitin created a sprint dashboard for the 1.0.0-alpha1 release [1].
> I’ve added a few issues to it based on the licensing reviews Niall and Dick
> are doing.  Here’s the summary:
>
> *** GEODE-32 / wiki page to document release process [2]
>
> Looks pretty good good.  There are a few inline question marks to fill out.
>
> *** GEODE-18 / source file headers
> *** GEODE-608 / Integrate RAT into build
> I’ve added build support for RAT on the feature/GEODE-608 branch.  This
> should make closing out GEODE-18 easier.  The excludes file is based on the
> one attached to GEODE-18.  There are a few more files to evaluate and the
> entire excludes list should be reviewed for correctness.
>
> *** GEODE-610 / Review LICENSE and NOTICE
>
> Niall exported the source and dependent licenses that need to be fed into
> edits on the LICENSE and NOTICE files.
>
> *** GEODE-611 / Replace Findbugs annotations
>
> We can replace the LGPL-licensed findbugs annotation library with an ASL
> clean implementation.
>
>
> Anthony
>
>
> [1]
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=92&view=planning
> [2]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=57311453
>
>


-- 
-John
503-504-8657
john.blum10101 (skype)

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #143 was SUCCESSFUL (with 1214 tests). Change made by Jens Deppe.

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #143 was successful.
---
This was manually triggered by Jens Deppe.
1218 tests in total.

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




--
Code Changes
--
Jens Deppe (251199a5cc61a4643400abc4c3bd360e3df8dad7):

>SGF-447: Replace GemFire internal StringUtils with Spring standard StringUtils



--
This message is automatically generated by Atlassian Bamboo

Build failed in Jenkins: Geode-nightly #296

[Apache Jenkins Server]

See 

--
[...truncated 273 lines...]
:gemfire-assembly:distZip
:gemfire-assembly:jar SKIPPED
:gemfire-assembly:assemble
:gemfire-core:compileTestJava:22:
 warning: Unsafe is internal proprietary API and may be removed in a future 
release
import sun.misc.Unsafe;
   ^
:22:
 warning: Unsafe is internal proprietary API and may be removed in a future 
release
import sun.misc.Unsafe;
   ^
:22:
 warning: Unsafe is internal proprietary API and may be removed in a future 
release
import sun.misc.Unsafe;
   ^
Note: 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.
3 warnings

:gemfire-core:processTestResources
:gemfire-core:testClasses
:gemfire-core:jarTest
:gemfire-assembly:compileTestJava
:gemfire-assembly:processTestResources UP-TO-DATE
:gemfire-assembly:testClasses
:gemfire-assembly:checkMissedTests
:gemfire-assembly:installDist
:gemfire-assembly:test
Build file ': 
line 70
AvailablePortFinder has been deprecated and is scheduled to be removed in 
Gradle 3.0
:gemfire-assembly:check
:gemfire-assembly:build
:gemfire-assembly:distributedTest UP-TO-DATE
:gemfire-assembly:integrationTest
:gemfire-common:assemble
:gemfire-common:compileTestJava
:gemfire-common:processTestResources UP-TO-DATE
:gemfire-common:testClasses
:gemfire-common:checkMissedTests
:gemfire-common:test
:gemfire-common:check
:gemfire-common:build
:gemfire-common:distributedTest UP-TO-DATE
:gemfire-common:integrationTest
:gemfire-core:assemble
:gemfire-core:checkMissedTests
:gemfire-core:test
:gemfire-core:check
:gemfire-core:build
:gemfire-core:distributedTest

com.gemstone.gemfire.internal.cache.partitioned.PersistentPartitionedRegionOldConfigDUnitTest
 > testMissingMemberRedundancy1 FAILED
junit.framework.AssertionFailedError: expected:<[]> but was:<[14]>

6703 tests completed, 1 failed
:gemfire-core:distributedTest FAILED
:gemfire-core:integrationTestjava.lang.Throwable
at 
com.gemstone.gemfire.test.process.ProcessStreamReader.start(ProcessStreamReader.java:62)
at 
com.gemstone.gemfire.test.process.ProcessOutputReader.waitFor(ProcessOutputReader.java:47)
at 
com.gemstone.gemfire.test.process.ProcessWrapper.start(ProcessWrapper.java:330)
at 
com.gemstone.gemfire.test.process.ProcessWrapper.access$000(ProcessWrapper.java:47)
at 
com.gemstone.gemfire.test.process.ProcessWrapper$1.run(ProcessWrapper.java:260)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: Stream closed
at 
java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:170)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:283)
at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
at java.io.InputStreamReader.read(InputStreamReader.java:184)

:gemfire-joptsimple:assemble
:gemfire-joptsimple:compileTestJava UP-TO-DATE
:gemfire-joptsimple:processTestResources UP-TO-DATE
:gemfire-joptsimple:testClasses UP-TO-DATE
:gemfire-joptsimple:checkMissedTests UP-TO-DATE
:gemfire-joptsimple:test UP-TO-DATE
:gemfire-joptsimple:check
:gemfire-joptsimple:build
:gemfire-joptsimple:distributedTest UP-TO-DATE
:gemfire-joptsimple:integrationTest UP-TO-DATE
:gemfire-json:assemble
:gemfire-json:compileTestJava UP-TO-DATE
:gemfire-json:processTestResources UP-TO-DATE
:gemfire-json:testClasses UP-TO-DATE
:gemfire-json:checkMissedTests UP-TO-DATE
:gemfire-json:test UP-TO-DATE
:gemfire-json:check
:gemfire-json:build
:gemfire-json:distributedTest UP-TO-DATE
:gemfire-json:integrationTest UP-TO-DATE
:gemfire-junit:jar
:gemfire-junit:assemble
:gemfire-junit:checkMissedTests
:gemfire-junit:test
:gemfire-junit:check
:gemfire-junit:build
:gemfire-junit:distributedTest UP-TO-DATE
:gemfire-junit:integrationTest
:gemfire-lucene:assemble
:gemfire-lucene:compileTestJavaNote: 

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