Geode unit tests completed in 'develop/DistributedTest' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/76

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #955 was SUCCESSFUL (with 2423 tests). Change made by John Blum.

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #955 was successful.
---
Scheduled with changes by John Blum.
2425 tests in total.

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




--
Code Changes
--
John Blum (f4c7d58ad055f7f967d1e5532480d7618c29cf5c):

>DATAGEODE-128 - Allow CacheTypeAwareFactoryBean to register interests on 
>client Region creation and implement SmartLifecycle.

John Blum (70ee237810648d4280ac6216953a61f50f4cde30):

>DATAGEODE-124 - Relax type matching for resolving Function arguments in 
>FunctionContextInjectingArgumentResolver.



--
This message is automatically generated by Atlassian Bamboo

Re: OPLOG_MAGIC_SEQ_ID

[Anthony Baker]

Yea, I wouldn’t change this.  Ideally each type of binary file would have a 
different magic seq to be easily distinguishable.

Anthony


> On Jun 21, 2018, at 3:01 PM, Kirk Lund  wrote:
> 
> Lesson: javadocs lie
> 
> Do the two different values really need to be different? And because of
> backwards compatibility we're stuck with this.
> 
> On Thu, Jun 21, 2018 at 1:49 PM, Anthony Baker  wrote:
> 
>> From a brief review of the source code, I believe that:
>> 
>>DiskInitFile.OPLOG_MAGIC_SEQ_ID is used for *.if files
>>Oplog.OPLOG_MAGIC_SEQ_ID is used for all other oplog file types
>> 
>> HTH,
>> Anthony
>> 
>> 
>> 
>> 
>>> On Jun 21, 2018, at 1:36 PM, Kirk Lund  wrote:
>>> 
>>> Please help me understand OPLOG_MAGIC_SEQ_ID in the oplog code...
>>> 
>>> There is a constant called OPLOG_MAGIC_SEQ_ID which is a byte
>> representing
>>> the beginning of every oplog file. Makes sense so far.
>>> 
>>> There are two different constants called OPLOG_MAGIC_SEQ_ID each with a
>>> different value. One is in Oplog.java and the other is in
>> DiskInitFile.java
>>> (IF). The javadocs of each seems to imply that every oplog type has its
>> own
>>> different magic number. But the javadocs also list CRF, DRF, KRF, IF (and
>>> IRF but only in Oplog.java) as the Oplog types. If that's the explanation
>>> for why we have two different values, then should we have a different
>>> constant for each Oplog file type?
>>> 
>>> I started refactoring all of these byte constants into an Enum so that I
>>> can use Enum names in trace log statements instead of cryptic byte codes
>>> but then found some of these constants are defined in more than one place
>>> with different values.
>>> 
>>> Oplog.java:
>>> 
>>> /**
>>>  * Persist oplog file magic number. Written once at the beginning of
>>> every oplog file; CRF, DRF,
>>>  * KRF, IF and IRF. Followed by 6 byte magic number. Each oplog type has
>>> a different magic number
>>>  * Followed by EndOfRecord Fix for bug 43824
>>>  *
>>>  * @since GemFire 8.0
>>>  */
>>> static final byte OPLOG_MAGIC_SEQ_ID = 92;
>>> 
>>> DiskInitFile.java:
>>> 
>>> /**
>>>  * Persist oplog file magic number. Written once at the beginning of
>>> every oplog file; CRF, DRF,
>>>  * KRF, and IF. Followed by 6 byte magic number. Each oplog type has a
>>> different magic number
>>>  * Followed by EndOfRecord Fix for bug 43824
>>>  *
>>>  * @since GemFire 8.0
>>>  */
>>> public static final byte OPLOG_MAGIC_SEQ_ID = 89;
>> 
>> 

Re: OPLOG_MAGIC_SEQ_ID

[Kirk Lund]

Lesson: javadocs lie

Do the two different values really need to be different? And because of
backwards compatibility we're stuck with this.

On Thu, Jun 21, 2018 at 1:49 PM, Anthony Baker  wrote:

> From a brief review of the source code, I believe that:
>
> DiskInitFile.OPLOG_MAGIC_SEQ_ID is used for *.if files
> Oplog.OPLOG_MAGIC_SEQ_ID is used for all other oplog file types
>
> HTH,
> Anthony
>
>
>
>
> > On Jun 21, 2018, at 1:36 PM, Kirk Lund  wrote:
> >
> > Please help me understand OPLOG_MAGIC_SEQ_ID in the oplog code...
> >
> > There is a constant called OPLOG_MAGIC_SEQ_ID which is a byte
> representing
> > the beginning of every oplog file. Makes sense so far.
> >
> > There are two different constants called OPLOG_MAGIC_SEQ_ID each with a
> > different value. One is in Oplog.java and the other is in
> DiskInitFile.java
> > (IF). The javadocs of each seems to imply that every oplog type has its
> own
> > different magic number. But the javadocs also list CRF, DRF, KRF, IF (and
> > IRF but only in Oplog.java) as the Oplog types. If that's the explanation
> > for why we have two different values, then should we have a different
> > constant for each Oplog file type?
> >
> > I started refactoring all of these byte constants into an Enum so that I
> > can use Enum names in trace log statements instead of cryptic byte codes
> > but then found some of these constants are defined in more than one place
> > with different values.
> >
> > Oplog.java:
> >
> >  /**
> >   * Persist oplog file magic number. Written once at the beginning of
> > every oplog file; CRF, DRF,
> >   * KRF, IF and IRF. Followed by 6 byte magic number. Each oplog type has
> > a different magic number
> >   * Followed by EndOfRecord Fix for bug 43824
> >   *
> >   * @since GemFire 8.0
> >   */
> >  static final byte OPLOG_MAGIC_SEQ_ID = 92;
> >
> > DiskInitFile.java:
> >
> >  /**
> >   * Persist oplog file magic number. Written once at the beginning of
> > every oplog file; CRF, DRF,
> >   * KRF, and IF. Followed by 6 byte magic number. Each oplog type has a
> > different magic number
> >   * Followed by EndOfRecord Fix for bug 43824
> >   *
> >   * @since GemFire 8.0
> >   */
> >  public static final byte OPLOG_MAGIC_SEQ_ID = 89;
>
>

Resolving geode-pulse compilation errors in IntelliJ

[Kirk Lund]

After the recent Gradle upgrade, you might see some compilation errors in
IntelliJ involving geode-pulse such as the following:

/Users/klund/dev/gemfire/open/geode-pulse/src/main/java/org/
apache/geode/tools/pulse/internal/service/MemberDetailsService.java
Error:(28, 46) java: package org.springframework.context.annotation does
not exist
Error:(29, 38) java: package org.springframework.stereotype does not exist
Error:(30, 38) java: package org.springframework.stereotype does not exist
Error:(42, 2) java: cannot find symbol
  symbol: class Component
Error:(43, 2) java: cannot find symbol
  symbol: class Service
Error:(44, 2) java: cannot find symbol
  symbol: class Scope

To resolve this, open:

Preferences -> Build, Execution, Deployment -> BuildTools -> Gradle

There you’ll see your Geode project under the “Linked Gradle projects” —
you need to select it and then deselect “Create separate module per source
set.”

This worked for me.

Thanks,
Kirk

Re: Revert recent Gradle upgrade

[Jianxia Chen]

The long build time might be due to the old version of gradle daemon (pre
4.8). Try kill it if you have one running.

On Thu, Jun 21, 2018 at 1:42 PM Jacob Barrett  wrote:

> I am suffering quite the opposite with 8.4 and seeing much longer build
> times and rebuilds on things that have not changed.
>
> > On Jun 21, 2018, at 12:47 PM, Jens Deppe  wrote:
> >
> > I have a fix which I think will resolve the current problems:
> > https://github.com/apache/geode/pull/2074 (currently running
> precheckin).
> >
> > It does require deferring IntelliJ's build to gradle (which may slow some
> > tasks down a bit) but will at least let you continue to work.
> >
> > The perceived slowdown should be mitigated to a large part by Gradle
> 4.8's
> > ability to cache build results.
> >
> > I'd encourage you to grab the diff and see if it helps.
> >
> > --Jens
> >
> >> On Thu, Jun 21, 2018 at 12:19 PM, Kirk Lund  wrote:
> >>
> >> I think we should revert the recent Gradle upgrade. This change
> apparently
> >> causes IntelliJ to not be able to build Geode which prevents us from
> >> running any Tests in the IDE.
> >>
> >> I'd prefer to fix how IntelliJ works with our project but we cannot be
> >> without the ability to debug tests. I don't know enough to fix this
> >> problem.
> >>
> >> If we can't fix the ability to run Tests in the IDE, then we should
> revert
> >> this commit:
> >>
> >> commit 7685375ea7229ad0e0fc9ea188cccfa56ff7d8ef
> >> Author: Robert Houghton <
> 32176082+rhoughton-pi...@users.noreply.github.com
> >>>
> >> Date:   Tue Jun 19 08:28:51 2018 -0700
> >>
> >>GEODE-4791: Enable gradle 4.8 for features and futureproofing (#2050)
> >>
> >>Enable:
> >>* Java 10 (when ready)
> >>* remove deprecated configuration settings
> >>* build-cache
> >>* incremental
> >>* Update classpath/srcpath logic
> >>
> >>Disable:
> >>* parallel (to fix Tomcat tests bind issues)
> >>
> >>Signed-off-by: Robert Houghton 
> >>Signed-off-by: Jens Deppe 
> >>Signed-off-by: Robert Houghton 
> >>Signed-off-by: Jens Deppe 
> >>
>

Re: OPLOG_MAGIC_SEQ_ID

[Anthony Baker]

From a brief review of the source code, I believe that:

DiskInitFile.OPLOG_MAGIC_SEQ_ID is used for *.if files
Oplog.OPLOG_MAGIC_SEQ_ID is used for all other oplog file types

HTH,
Anthony




> On Jun 21, 2018, at 1:36 PM, Kirk Lund  wrote:
> 
> Please help me understand OPLOG_MAGIC_SEQ_ID in the oplog code...
> 
> There is a constant called OPLOG_MAGIC_SEQ_ID which is a byte representing
> the beginning of every oplog file. Makes sense so far.
> 
> There are two different constants called OPLOG_MAGIC_SEQ_ID each with a
> different value. One is in Oplog.java and the other is in DiskInitFile.java
> (IF). The javadocs of each seems to imply that every oplog type has its own
> different magic number. But the javadocs also list CRF, DRF, KRF, IF (and
> IRF but only in Oplog.java) as the Oplog types. If that's the explanation
> for why we have two different values, then should we have a different
> constant for each Oplog file type?
> 
> I started refactoring all of these byte constants into an Enum so that I
> can use Enum names in trace log statements instead of cryptic byte codes
> but then found some of these constants are defined in more than one place
> with different values.
> 
> Oplog.java:
> 
>  /**
>   * Persist oplog file magic number. Written once at the beginning of
> every oplog file; CRF, DRF,
>   * KRF, IF and IRF. Followed by 6 byte magic number. Each oplog type has
> a different magic number
>   * Followed by EndOfRecord Fix for bug 43824
>   *
>   * @since GemFire 8.0
>   */
>  static final byte OPLOG_MAGIC_SEQ_ID = 92;
> 
> DiskInitFile.java:
> 
>  /**
>   * Persist oplog file magic number. Written once at the beginning of
> every oplog file; CRF, DRF,
>   * KRF, and IF. Followed by 6 byte magic number. Each oplog type has a
> different magic number
>   * Followed by EndOfRecord Fix for bug 43824
>   *
>   * @since GemFire 8.0
>   */
>  public static final byte OPLOG_MAGIC_SEQ_ID = 89;

Re: Revert recent Gradle upgrade

[Jacob Barrett]

I am suffering quite the opposite with 8.4 and seeing much longer build times 
and rebuilds on things that have not changed. 

> On Jun 21, 2018, at 12:47 PM, Jens Deppe  wrote:
> 
> I have a fix which I think will resolve the current problems:
> https://github.com/apache/geode/pull/2074 (currently running precheckin).
> 
> It does require deferring IntelliJ's build to gradle (which may slow some
> tasks down a bit) but will at least let you continue to work.
> 
> The perceived slowdown should be mitigated to a large part by Gradle 4.8's
> ability to cache build results.
> 
> I'd encourage you to grab the diff and see if it helps.
> 
> --Jens
> 
>> On Thu, Jun 21, 2018 at 12:19 PM, Kirk Lund  wrote:
>> 
>> I think we should revert the recent Gradle upgrade. This change apparently
>> causes IntelliJ to not be able to build Geode which prevents us from
>> running any Tests in the IDE.
>> 
>> I'd prefer to fix how IntelliJ works with our project but we cannot be
>> without the ability to debug tests. I don't know enough to fix this
>> problem.
>> 
>> If we can't fix the ability to run Tests in the IDE, then we should revert
>> this commit:
>> 
>> commit 7685375ea7229ad0e0fc9ea188cccfa56ff7d8ef
>> Author: Robert Houghton <32176082+rhoughton-pi...@users.noreply.github.com
>>> 
>> Date:   Tue Jun 19 08:28:51 2018 -0700
>> 
>>GEODE-4791: Enable gradle 4.8 for features and futureproofing (#2050)
>> 
>>Enable:
>>* Java 10 (when ready)
>>* remove deprecated configuration settings
>>* build-cache
>>* incremental
>>* Update classpath/srcpath logic
>> 
>>Disable:
>>* parallel (to fix Tomcat tests bind issues)
>> 
>>Signed-off-by: Robert Houghton 
>>Signed-off-by: Jens Deppe 
>>Signed-off-by: Robert Houghton 
>>Signed-off-by: Jens Deppe 
>> 

OPLOG_MAGIC_SEQ_ID

[Kirk Lund]

Please help me understand OPLOG_MAGIC_SEQ_ID in the oplog code...

There is a constant called OPLOG_MAGIC_SEQ_ID which is a byte representing
the beginning of every oplog file. Makes sense so far.

There are two different constants called OPLOG_MAGIC_SEQ_ID each with a
different value. One is in Oplog.java and the other is in DiskInitFile.java
(IF). The javadocs of each seems to imply that every oplog type has its own
different magic number. But the javadocs also list CRF, DRF, KRF, IF (and
IRF but only in Oplog.java) as the Oplog types. If that's the explanation
for why we have two different values, then should we have a different
constant for each Oplog file type?

I started refactoring all of these byte constants into an Enum so that I
can use Enum names in trace log statements instead of cryptic byte codes
but then found some of these constants are defined in more than one place
with different values.

Oplog.java:

  /**
   * Persist oplog file magic number. Written once at the beginning of
every oplog file; CRF, DRF,
   * KRF, IF and IRF. Followed by 6 byte magic number. Each oplog type has
a different magic number
   * Followed by EndOfRecord Fix for bug 43824
   *
   * @since GemFire 8.0
   */
  static final byte OPLOG_MAGIC_SEQ_ID = 92;

DiskInitFile.java:

  /**
   * Persist oplog file magic number. Written once at the beginning of
every oplog file; CRF, DRF,
   * KRF, and IF. Followed by 6 byte magic number. Each oplog type has a
different magic number
   * Followed by EndOfRecord Fix for bug 43824
   *
   * @since GemFire 8.0
   */
  public static final byte OPLOG_MAGIC_SEQ_ID = 89;

DataEngConf 2018

[Addison Huddy]

Hi Apache Geode Community,

Wanted to send out a link to a talk I gave at DataEncConf 2018
entitled "What the heck is an In-Memory Data Grid?"  The talk highlights
Apache Geode and the IMDG space.

https://www.youtube.com/watch?v=gAw5MVdIhbQ

If you haven't heard of DataEngConf (http://www.dataengconf.com/), I highly
recommend attending.  The conference organizers really ensure that the
conference is for developers first and foremost and that the content
focuses on deeply technical topics.

All the videos from DataEngConf 2018 can be found here:
https://www.youtube.com/user/g33ktalktv/playlists


Best,
Addison

Re: Revert recent Gradle upgrade

[Jens Deppe]

I have a fix which I think will resolve the current problems:
https://github.com/apache/geode/pull/2074 (currently running precheckin).

It does require deferring IntelliJ's build to gradle (which may slow some
tasks down a bit) but will at least let you continue to work.

The perceived slowdown should be mitigated to a large part by Gradle 4.8's
ability to cache build results.

I'd encourage you to grab the diff and see if it helps.

--Jens

On Thu, Jun 21, 2018 at 12:19 PM, Kirk Lund  wrote:

> I think we should revert the recent Gradle upgrade. This change apparently
> causes IntelliJ to not be able to build Geode which prevents us from
> running any Tests in the IDE.
>
> I'd prefer to fix how IntelliJ works with our project but we cannot be
> without the ability to debug tests. I don't know enough to fix this
> problem.
>
> If we can't fix the ability to run Tests in the IDE, then we should revert
> this commit:
>
> commit 7685375ea7229ad0e0fc9ea188cccfa56ff7d8ef
> Author: Robert Houghton <32176082+rhoughton-pi...@users.noreply.github.com
> >
> Date:   Tue Jun 19 08:28:51 2018 -0700
>
> GEODE-4791: Enable gradle 4.8 for features and futureproofing (#2050)
>
> Enable:
> * Java 10 (when ready)
> * remove deprecated configuration settings
> * build-cache
> * incremental
> * Update classpath/srcpath logic
>
> Disable:
> * parallel (to fix Tomcat tests bind issues)
>
> Signed-off-by: Robert Houghton 
> Signed-off-by: Jens Deppe 
> Signed-off-by: Robert Houghton 
> Signed-off-by: Jens Deppe 
>

Revert recent Gradle upgrade

[Kirk Lund]

I think we should revert the recent Gradle upgrade. This change apparently
causes IntelliJ to not be able to build Geode which prevents us from
running any Tests in the IDE.

I'd prefer to fix how IntelliJ works with our project but we cannot be
without the ability to debug tests. I don't know enough to fix this problem.

If we can't fix the ability to run Tests in the IDE, then we should revert
this commit:

commit 7685375ea7229ad0e0fc9ea188cccfa56ff7d8ef
Author: Robert Houghton <32176082+rhoughton-pi...@users.noreply.github.com>
Date:   Tue Jun 19 08:28:51 2018 -0700

GEODE-4791: Enable gradle 4.8 for features and futureproofing (#2050)

Enable:
* Java 10 (when ready)
* remove deprecated configuration settings
* build-cache
* incremental
* Update classpath/srcpath logic

Disable:
* parallel (to fix Tomcat tests bind issues)

Signed-off-by: Robert Houghton 
Signed-off-by: Jens Deppe 
Signed-off-by: Robert Houghton 
Signed-off-by: Jens Deppe 

package org.springframework.stereotype does not exist

[Kirk Lund]

Last week, I was able to build and execute tests in IntelliJ, but after
pulling latest changes on develop (include the Gradle upgrade) I'm now
getting errors in every class that uses org.springframework classes.

Any ideas how to fix this?

/Users/klund/dev/gemfire/open/geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/service/MemberDetailsService.java
Error:(28, 46) java: package org.springframework.context.annotation does
not exist
Error:(29, 38) java: package org.springframework.stereotype does not exist
Error:(30, 38) java: package org.springframework.stereotype does not exist
Error:(42, 2) java: cannot find symbol
  symbol: class Component
Error:(43, 2) java: cannot find symbol
  symbol: class Service
Error:(44, 2) java: cannot find symbol
  symbol: class Scope

Thanks,
Kirk

Build failed in Jenkins: Geode-nightly #1231

[Apache Jenkins Server]

See 


Changes:

[nag] GEODE-5109: Ignoring the test

[github] GEODE-5333: Destroy failed connection in ConnectionConnector (#2072)

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

> Task :geode-connectors:processTestResources
> Task :geode-connectors:testClasses
> Task :geode-connectors:checkMissedTests
> Task :geode-connectors:spotlessJava UP-TO-DATE
> Task :geode-connectors:spotlessJavaCheck UP-TO-DATE
> Task :geode-connectors:spotlessCheck UP-TO-DATE
> Task :geode-connectors:test
> Task :geode-core:assemble
> Task :geode-core:checkMissedTests
> Task :geode-core:spotlessJava
> Task :geode-core:spotlessJavaCheck
> Task :geode-core:spotlessCheck
> Task :geode-core:test
> Task :geode-cq:assemble

> Task :geode-cq:compileTestJava
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.

> Task :geode-cq:processTestResources
> Task :geode-cq:testClasses
> Task :geode-cq:checkMissedTests
> Task :geode-cq:spotlessJava UP-TO-DATE
> Task :geode-cq:spotlessJavaCheck UP-TO-DATE
> Task :geode-cq:spotlessCheck UP-TO-DATE
> Task :geode-cq:test
> Task :geode-experimental-driver:jar
> Task :geode-experimental-driver:javadoc FROM-CACHE
> Task :geode-experimental-driver:javadocJar
> Task :geode-experimental-driver:sourcesJar
> Task :geode-experimental-driver:signArchives SKIPPED
> Task :geode-experimental-driver:assemble

> Task :geode-experimental-driver:compileTestJava
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :geode-experimental-driver:processTestResources
> Task :geode-experimental-driver:testClasses
> Task :geode-experimental-driver:checkMissedTests
> Task :geode-experimental-driver:spotlessJava UP-TO-DATE
> Task :geode-experimental-driver:spotlessJavaCheck UP-TO-DATE
> Task :geode-experimental-driver:spotlessCheck UP-TO-DATE
> Task :geode-experimental-driver:test
> Task :geode-json:assemble
> Task :geode-json:compileTestJava NO-SOURCE
> Task :geode-json:processTestResources
> Task :geode-json:testClasses
> Task :geode-json:checkMissedTests NO-SOURCE
> Task :geode-json:spotlessJava UP-TO-DATE
> Task :geode-json:spotlessJavaCheck UP-TO-DATE
> Task :geode-json:spotlessCheck UP-TO-DATE
> Task :geode-json:test NO-SOURCE
> Task :geode-old-versions:javadoc
> Task :geode-junit:javadoc
> Task :geode-junit:javadocJar
> Task :geode-junit:sourcesJar
> Task :geode-junit:signArchives SKIPPED
> Task :geode-junit:assemble
> Task :geode-junit:compileTestJava FROM-CACHE
> Task :geode-junit:processTestResources
> Task :geode-junit:testClasses
> Task :geode-junit:checkMissedTests
> Task :geode-junit:spotlessJava UP-TO-DATE
> Task :geode-junit:spotlessJavaCheck UP-TO-DATE
> Task :geode-junit:spotlessCheck UP-TO-DATE
> Task :geode-junit:test
> Task :geode-lucene:assemble

> Task :geode-lucene:compileTestJava
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.

> Task :geode-lucene:processTestResources
> Task :geode-lucene:testClasses
> Task :geode-lucene:checkMissedTests
> Task :geode-lucene:spotlessJava
> Task :geode-lucene:spotlessJavaCheck
> Task :geode-lucene:spotlessCheck
> Task :geode-lucene:test
> Task :geode-old-client-support:assemble
> Task :geode-old-client-support:compileTestJava
> Task :geode-old-client-support:processTestResources NO-SOURCE
> Task :geode-old-client-support:testClasses
> Task :geode-old-client-support:checkMissedTests
> Task :geode-old-client-support:spotlessJava UP-TO-DATE
> Task :geode-old-client-support:spotlessJavaCheck UP-TO-DATE
> Task :geode-old-client-support:spotlessCheck UP-TO-DATE
> Task :geode-old-client-support:test
> Task :geode-old-versions:javadocJar
> Task :geode-old-versions:sourcesJar
> Task :geode-old-versions:signArchives SKIPPED
> Task :geode-old-versions:assemble
> Task :geode-old-versions:compileTestJava FROM-CACHE
> Task :geode-old-versions:processTestResources NO-SOURCE
> Task :geode-old-versions:testClasses UP-TO-DATE
> Task :geode-old-versions:checkMissedTests
> Task :geode-old-versions:spotlessJava UP-TO-DATE
> Task :geode-old-versions:spotlessJavaCheck UP-TO-DATE
> Task :geode-old-versions:spotlessCheck UP-TO-DATE
> Task :geode-old-versions:test
> Task :geode-protobuf:assemble

> Task :geode-protobuf:compileTestJava
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.

> Task :geode-protobuf:processTestRes