Build failed in Jenkins: Geode-release #103

2018-01-07 Thread Apache Jenkins Server 
See 

--
[...truncated 184.63 KB...]
:geode-common:processTestResources NO-SOURCE
:geode-common:testClasses
:geode-common:checkMissedTests
:geode-common:spotlessJavaCheck
:geode-common:spotlessCheck
:geode-common:test
:geode-common:distributedTest
:geode-common:integrationTest
:geode-concurrency-test:jar
:geode-concurrency-test:javadoc
:geode-concurrency-test:javadocJar
:geode-concurrency-test:sourcesJar
:geode-concurrency-test:signArchives SKIPPED
:geode-concurrency-test:assemble
:geode-concurrency-test:generateJpfProperties
:geode-concurrency-test:compileTestJava NO-SOURCE
:geode-concurrency-test:processTestResources NO-SOURCE
:geode-concurrency-test:testClasses UP-TO-DATE
:geode-concurrency-test:checkMissedTests NO-SOURCE
:geode-concurrency-test:spotlessJavaCheck
:geode-concurrency-test:spotlessCheck
:geode-concurrency-test:test NO-SOURCE
:geode-concurrency-test:distributedTest NO-SOURCE
:geode-concurrency-test:integrationTest NO-SOURCE
:geode-connectors:assemble
:geode-connectors:compileTestJavaNote: Some input files use unchecked or unsafe 
operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-connectors:processTestResources NO-SOURCE
:geode-connectors:testClasses
:geode-connectors:checkMissedTests
:geode-connectors:spotlessJavaCheck
:geode-connectors:spotlessCheck
:geode-connectors:test
:geode-connectors:distributedTest
:geode-connectors:integrationTest
:geode-core:assemble
:geode-core:checkMissedTests
:geode-core:spotlessJavaCheck
:geode-core:spotlessCheck
:geode-core:test
:geode-core:distributedTest
:geode-core:integrationTest
:geode-cq:assemble
:geode-cq:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

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

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

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

:geode-junit:processTestResources
:geode-junit:testClasses
:geode-junit:checkMissedTests
:geode-junit:spotlessJavaCheck
:geode-junit:spotlessCheck
:geode-junit:test
:geode-junit:distributedTest
:geode-junit:integrationTest
:geode-lucene:assemble
:geode-lucene:compileTestJava
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-test-framework/6.4.1/lucene-test-framework-6.4.1.pom
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-codecs/6.4.1/lucene-codecs-6.4.1.pom
Download 
https://repo1.maven.org/maven2/com/carrotsearch/randomizedtesting/randomizedtesting-runner/2.4.0/randomizedtesting-runner-2.4.0.pom
Download 
https://repo1.maven.org/maven2/com/carrotsearch/randomizedtesting/randomizedtesting-parent/2.4.0/randomizedtesting-parent-2.4.0.pom
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-test-framework/6.4.1/lucene-test-framework-6.4.1.jar
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-codecs/6.4.1/lucene-codecs-6.4.1.jar
Download 
https://repo1.maven.org/maven2/com/carrotsearch/randomizedtesting/randomizedtesting-runner/2.4.0/randomizedtesting-runner-2.4.0.jar
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.

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

2018-01-07 Thread Spring CI 

---
Spring Data GemFire > Nightly-ApacheGeode > #790 was successful.
---
Scheduled
2326 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Re: [DISCUSS] Benchmarks module package structure

2018-01-07 Thread Xiaojian Zhou 
The package might be always a problem. Even you put the cq benchmark code
under geode-cq to near its source code, it might still have to access code
under other package, such as geode-core.

So I think put benchmark test code under benchmark package is ok. Your
option 2) is good.

Regards
Gester

On Fri, Jan 5, 2018 at 11:57 AM, Nick Reich  wrote:

> Team,
>
> I am in the progress of adding new benchmarks to the (currently sparse)
> geode-benchmarks module. The lack of current examples in the module leads
> me to wonder what the correct organization of benchmarks in the module is
> (and if this is the right location).
>
> The existing benchmarks are all in org.apache.geode.cache.benchmark.
> Following this pattern would (presumably) result in benchmark subpackages
> in each package that has benchmarks. Making the root package
> org.apache.geode.benchmark would remove this proliferation of sub packages.
> However, both these approaches have the issue that package level
> methods/classes cannot be accessed from benchmarks as they will never share
> a package with the production code.
>
> 1) Should benchmarks then not be put in special benchmark packages?
>
> 2) Should our benchmarks not invoke package level methods/classes in the
> case that we should use benchmark packages? Or should such benchmarks not
> reside in the benchmarks module?
>
> 3) Is geode-benchmarks where we intend all benchmarks, only certain classes
> of benchmarks (all using jmh for example), or would we prefer embedding
> them in the modules where the code being benchmarked resides?
>
> Thanks for your input.
>