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

[Apache Jenkins Server]

See 

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

[apachegeodeci]

Pipeline results can be found at:

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

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

[Apache Jenkins Server]

See 


Changes:

[dschneider] GEODE-4161: fix gfsh describe jdbc-mapping

[github] GEODE-4191: Replace imports of io.codearte..Mockito with

[github] GEODE-4193: fix password file security in JMX (#1227)

[github] GEODE-4131: Do not reference deployed jars as byte arrays anymore

[nabarunnag] GEODE-4096: Fixed race condition for connection global variable

[lhughesgodfrey] GEODE-4144: EventId in client does not match that of server 
(with

[lhughesgodfrey] GEODE-4165: Listener EventId in server does not match that of 
the client

[sbawaskar] rev the version number since a release branch has been created for 
1.4.0

[nabarunnag] GEODE-4184: Handled concurrent access of HashSet

[lhughesgodfrey] GEODE-4177: client does not receive all put all creates when 
servers

[bschuchardt] GEODE-4229 CI failure due to suspect string: "Locator socket was 
closed

[nabarunnag] GEODE-4135: Awaitility condition added

[metatype] Fix script so passing.txt is branch-dependent.

[github] GEODE-4131: add the deprecated API in MemberMXBean (#1231)

[github] GEODE-4160: fix gfsh describe jdbc-connection (#1223)

[huynhja] GEODE-4221: Restore the ability to access the debugging VM. (#1234)

[dsmith] GEODE-4158: Correct the detection of Geode-internal classes for

[klund] GEODE-3965: rename DistributionManager classes

[klund] GEODE-3965: define exceptionInThreads methods in DistributionManager

[klund] GEODE-3965: rename and cleanup DistributionManager tests

[bschuchardt] GEODE-4192 GetServer request should return error if no servers 
found

--
[...truncated 140.29 KB...]
:geode-client-protocol:sourcesJar
:geode-client-protocol:signArchives SKIPPED
:geode-common:javadocJar
:geode-common:sourcesJar
:geode-common:signArchives SKIPPED
:geode-connectors:jar
:geode-connectors:javadoc
:geode-connectors:javadocJar
:geode-connectors:sourcesJar
:geode-connectors:signArchives SKIPPED
:geode-core:javadocJar
:geode-core:raJar
:geode-core:jcaJar
:geode-core:sourcesJar
:geode-core:signArchives SKIPPED
:geode-core:webJar
:geode-cq:jar
:geode-cq:javadoc
:geode-cq:javadocJar
:geode-cq:sourcesJar
:geode-cq:signArchives SKIPPED
:geode-json:javadocJar
:geode-json:sourcesJar
:geode-json:signArchives SKIPPED
:geode-lucene:jar
:geode-lucene:javadoc
:geode-lucene:javadocJar
:geode-lucene:sourcesJar
:geode-lucene:signArchives SKIPPED
:geode-old-client-support:jar
:geode-old-client-support:javadoc
:geode-old-client-support:javadocJar
:geode-old-client-support:sourcesJar
:geode-old-client-support:signArchives SKIPPED
:geode-protobuf:jar
:geode-protobuf-messages:javadoc
:geode-protobuf:javadoc
:geode-protobuf:javadocJar
:geode-protobuf:sourcesJar
:geode-protobuf:signArchives SKIPPED
:geode-protobuf-messages:javadocJar
:geode-protobuf-messages:sourcesJar
:geode-protobuf-messages:signArchives SKIPPED
:geode-protobuf-messages:zip
:geode-pulse:javadoc
:geode-pulse:javadocJar
:geode-pulse:sourcesJar
:geode-pulse:war
:geode-pulse:signArchives SKIPPED
:geode-rebalancer:jar
:geode-rebalancer:javadoc
:geode-rebalancer:javadocJar
:geode-rebalancer:sourcesJar
:geode-rebalancer:signArchives SKIPPED
:geode-wan:jar
:geode-wan:javadoc
:geode-wan:javadocJar
:geode-wan:sourcesJar
:geode-wan:signArchives SKIPPED
:geode-web:javadoc NO-SOURCE
:geode-web:javadocJar
:geode-web:sourcesJar
:geode-web:war
:geode-web:signArchives SKIPPED
:geode-web-api:javadoc
:geode-web-api:javadocJar
:geode-web-api:sourcesJar
:geode-web-api:war
:geode-web-api:signArchives SKIPPED
:geode-assembly:installDist
:geode-pulse:jar
:geode-assembly:compileTestJava
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core-uberjar/1.6.3/cargo-core-uberjar-1.6.3.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core/1.6.3/cargo-core-1.6.3.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/codehaus-cargo/1.6.3/codehaus-cargo-1.6.3.pom
Download 
https://repo1.maven.org/maven2/commons-discovery/commons-discovery/0.5/commons-discovery-0.5.pom
Download https://repo1.maven.org/maven2/org/apache/ant/ant/1.7.1/ant-1.7.1.pom
Download 
https://repo1.maven.org/maven2/org/apache/ant/ant-parent/1.7.1/ant-parent-1.7.1.pom
Download 
https://repo1.maven.org/maven2/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core-uberjar/1.6.3/cargo-core-uberjar-1.6.3.jar
Download 
https://repo1.maven.org/maven2/commons-discovery/commons-discovery/0.5/commons-discovery-0.5.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.
Note: Recompile with -Xlint:unchecked for details.
:geode-assembly:processTestResources
:geode-assembly:testClasses
:geode-assembly:flakyTest
:geode-benchmarks:compileTestJava NO-SOURCE
:geode-benchmarks:processTestResources NO-SOURCE

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

[apachegeodeci]

Pipeline results can be found at:

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

Errored: apache/geode#5433 (release/1.4.0 - 21d243d)

[Travis CI]

Build Update for apache/geode
-

Build: #5433
Status: Errored

Duration: 34 minutes and 19 seconds
Commit: 21d243d (release/1.4.0)
Author: jinmeiliao
Message: GEODE-4131: add the deprecated API in MemberMXBean (#1231)

(cherry picked from commit 78438f8)

View the changeset: 
https://github.com/apache/geode/compare/ecbaee5abbcf...21d243d95027

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/325574595?utm_source=email_medium=notification

--

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

Re: Next release: 1.4.0

[Anthony Baker]

I’ve updated the Jenkins nightly and release jobs.  Please ping me if you have 
any questions.

Anthony


> On Jan 5, 2018, at 10:00 AM, Anthony Baker  wrote:
> 
> +1
> 
> It should be pretty easy to clone the current pipeline for the 1.4.0 release 
> branch.
> 
> I’ll plan to update the Jenkins jobs to run the `build` and `updateArchives` 
> tasks since those still have value.
> 
> Anthony
> 

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

[apachegeodeci]

Pipeline results can be found at:

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

Re: Handling files and user.dir in tests

[Kirk Lund]

Just to help facilitate the discussion, here's a pull request that changes
GMSLocator from:

this.viewFile = new File(System.getProperty("user.dir"), "locator" +
server.getPort() + "view.dat");

...to:

this.viewFile = new File(System.getProperty("user.dir"), "locator" +
server.getPort() + "view.dat");

To allow the new test LocatorViewFileTemporaryFolderDUnitTest to redirect
the locator view dat file to a JUnit TemporaryFolder.

The only other way I can think of to this is to introduce a new Geode
property for "current-directory" which a test could specify. That property
value would have to be pushed down to every class that creates a new File.

Pull request: https://github.com/apache/geode/pull/1243

On Fri, Jan 5, 2018 at 3:32 PM, Kirk Lund  wrote:

> Any calls such as:
>
> File file = new File("myfile");
>
> ...results in creating a file in the current working directory of IntelliJ
> or Gradle when executing the test.
>
> I previously made a change to Gfsh so that tests can pass in a parent
> directory which will be used instead. This allowed me to change all of the
> Gfsh tests to write to a JUnit TemporaryFolder.
>
> This allows us to clean up ALL file artifacts produced from a test and
> also allows us to avoid file-based pollution from one test to another.
>
> I'd like to propose that we either always pass a parent directory into a
> component that produces file artifacts or change all of our code from using
> the constructor File(String pathname) to using the constructor File(String
> parent, String child).
>
> That 2nd approach would involve changing lines like this:
>
> File file = new File("myfile");
>
> ...to:
>
> File file = new File(System.getProperty("user.dir"), "myfile");
>
> Then if you add this line to a test:
>
> System.setProperty("user.dir", temporaryFolder.getRoot().
> getAbsolutePath());
>
> ...you're able to redirect all file artifacts to the JUnit TemporaryFolder.
>
> If we don't make this change to product code, then I really don't think we
> should be manipulating "user.dir" in ANY of our tests because the results
> are rather broken.
>
> If we don't like using "user.dir" then we could devise our own Geode
> system property for "the current working directory." Honestly, I don't care
> what system property we use or don't use, but I really want to have ALL
> file artifacts properly cleaned and deleted after every test. And I really
> want to prevent file-based test pollution.
>

Geode unit tests completed in 'release-1.4.0/IntegrationTest' with non-zero exit code

[apachegeodeci]

Pipeline results can be found at:

Concourse: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/release-1.4.0/jobs/IntegrationTest/builds/1

Handling files and user.dir in tests

[Kirk Lund]

Any calls such as:

File file = new File("myfile");

...results in creating a file in the current working directory of IntelliJ
or Gradle when executing the test.

I previously made a change to Gfsh so that tests can pass in a parent
directory which will be used instead. This allowed me to change all of the
Gfsh tests to write to a JUnit TemporaryFolder.

This allows us to clean up ALL file artifacts produced from a test and also
allows us to avoid file-based pollution from one test to another.

I'd like to propose that we either always pass a parent directory into a
component that produces file artifacts or change all of our code from using
the constructor File(String pathname) to using the constructor File(String
parent, String child).

That 2nd approach would involve changing lines like this:

File file = new File("myfile");

...to:

File file = new File(System.getProperty("user.dir"), "myfile");

Then if you add this line to a test:

System.setProperty("user.dir", temporaryFolder.getRoot().getAbsolutePath());

...you're able to redirect all file artifacts to the JUnit TemporaryFolder.

If we don't make this change to product code, then I really don't think we
should be manipulating "user.dir" in ANY of our tests because the results
are rather broken.

If we don't like using "user.dir" then we could devise our own Geode system
property for "the current working directory." Honestly, I don't care what
system property we use or don't use, but I really want to have ALL file
artifacts properly cleaned and deleted after every test. And I really want
to prevent file-based test pollution.

Re: Next release: 1.4.0

[Dan Smith]

I'm fine with switching off of Jenkins, we just need to be clear on what
our release criteria will be. It sounds like the new criteria being
proposed is that the concourse pipeline is passing for the release.

-Dan

On Thu, Jan 4, 2018 at 5:03 PM, Alexander Murmann 
wrote:

> The Concourse pipeline seems much more reliable at this point and the
> pipelines should be providing equivalent test coverage. Given that, are
> there any reasons to not deprecate Jenkins?
>
> On Thu, Jan 4, 2018 at 4:55 PM, Jason Huynh  wrote:
>
> > Hi Swapnil,
> >
> > GEODE-4140 was just marked for 1.4.  I think part of GEODE-4140 should be
> > fixed because the process.ClusterConfigurationNotAvailableException
> should
> > probably be reinstated.  If others don't think it's needed then feel free
> > to remove the fix tag.
> >
> > -Jason
> >
> > On Thu, Jan 4, 2018 at 4:38 PM Dan Smith  wrote:
> >
> > > Our process up to this point has been to not ship until the jenkins
> > builds
> > > on the release branch pass. We've been experimenting with concourse in
> > > parallel with jenkins, but the jenkins builds on develop at least are
> > still
> > > pretty messy. How are we going to ship this release? Should both be
> > > passing?
> > >
> > > -Dan
> > >
> > > On Thu, Jan 4, 2018 at 4:23 PM, Swapnil Bawaskar  >
> > > wrote:
> > >
> > > > Since all the issues tagged for 1.4.0 release
> > > >  > > > rapidView=92=GEODE=planning=
> > > > GEODE-3688=visible=12341842>
> > > > have been addressed, I went ahead and created a release branch for
> > 1.4.0.
> > > >
> > > > Can someone please update the concourse pipelines to pick up this
> > release
> > > > branch?
> > > >
> > > > Thanks!
> > > >
> > > >
> > > > On Tue, Nov 28, 2017 at 1:58 PM Swapnil Bawaskar <
> sbawas...@pivotal.io
> > >
> > > > wrote:
> > > >
> > > > > Well, making sure that the JIRA's status is up-to-date and removing
> > the
> > > > > 1.4.0 version tag if the fix can wait for a later release.
> > > > >
> > > > > On Tue, Nov 28, 2017 at 12:22 PM Michael William Dodge <
> > > > mdo...@pivotal.io>
> > > > > wrote:
> > > > >
> > > > >> What sort of update? I know that GEODE-4010 has a PR that's
> awaiting
> > > > >> review and merge.
> > > > >>
> > > > >> Sarge
> > > > >>
> > > > >> > On 28 Nov, 2017, at 10:03, Swapnil Bawaskar <
> sbawas...@pivotal.io
> > >
> > > > >> wrote:
> > > > >> >
> > > > >> > I would like to volunteer as a release manager.
> > > > >> > Currently there are 14 issues that are marked for 1.4.0. If you
> > are
> > > > >> working
> > > > >> > on any of these, can you please update the JIRA?
> > > > >> >
> > > > >> https://issues.apache.org/jira/secure/RapidBoard.jspa?
> > > > rapidView=92=GEODE=planning=
> > > > GEODE-3688=visible=12341842
> > > > >> >
> > > > >> > Thanks!
> > > > >> >
> > > > >> > On Tue, Nov 28, 2017 at 9:42 AM Anthony Baker <
> aba...@pivotal.io>
> > > > >> wrote:
> > > > >> >
> > > > >> >> Bump.  Any volunteers?  If not, I’ll do this.
> > > > >> >>
> > > > >> >> Anthony
> > > > >> >>
> > > > >> >>
> > > > >> >>> On Nov 22, 2017, at 1:48 PM, Anthony Baker  >
> > > > wrote:
> > > > >> >>>
> > > > >> >>> We released Geode 1.3.0 at the end of October.  Our next
> release
> > > > will
> > > > >> be
> > > > >> >> 1.4.0.  Questions:
> > > > >> >>>
> > > > >> >>> 1) Who wants to volunteer as a release manager?
> > > > >> >>> 2) What do we want to include in the release?
> > > > >> >>> 3) When do we want to do this?
> > > > >> >>>
> > > > >> >>> IMO, let's should shoot for an early Dec release.
> > > > >> >>>
> > > > >> >>> Anthony
> > > > >> >>>
> > > > >> >>
> > > > >> >>
> > > > >>
> > > > >>
> > > >
> > >
> >
>

Build failed in Jenkins: Geode-nightly #1065

[Apache Jenkins Server]

See 


Changes:

[bschuchardt] GEODE-4229 CI failure due to suspect string: "Locator socket was 
closed

[nabarunnag] GEODE-4135: Awaitility condition added

[metatype] Fix script so passing.txt is branch-dependent.

[github] GEODE-4131: add the deprecated API in MemberMXBean (#1231)

[github] GEODE-4160: fix gfsh describe jdbc-connection (#1223)

[huynhja] GEODE-4221: Restore the ability to access the debugging VM. (#1234)

[dsmith] GEODE-4158: Correct the detection of Geode-internal classes for

[klund] GEODE-3965: rename DistributionManager classes

[klund] GEODE-3965: define exceptionInThreads methods in DistributionManager

[klund] GEODE-3965: rename and cleanup DistributionManager tests

[bschuchardt] GEODE-4192 GetServer request should return error if no servers 
found

--
[...truncated 192.67 KB...]

:geode-cq:processTestResources
:geode-cq:testClasses
:geode-cq:checkMissedTests
:geode-cq:spotlessJavaCheck
:geode-cq:spotlessCheck
:geode-cq:test
: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-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-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-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.
Note: Recompile with -Xlint:unchecked for details.
:geode-lucene:processTestResources
:geode-lucene:testClasses
:geode-lucene:checkMissedTests
:geode-lucene:spotlessJavaCheck
:geode-lucene:spotlessCheck
:geode-lucene:test
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJavaNote: 

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

:geode-old-client-support:processTestResources NO-SOURCE
:geode-old-client-support:testClasses
:geode-old-client-support:checkMissedTests
:geode-old-client-support:spotlessJavaCheck
:geode-old-client-support:spotlessCheck
:geode-old-client-support:test
:geode-old-versions:javadoc NO-SOURCE
:geode-old-versions:javadocJar
:geode-old-versions:sourcesJar
:geode-old-versions:signArchives SKIPPED
:geode-old-versions:assemble
:geode-old-versions:compileTestJava NO-SOURCE
:geode-old-versions:processTestResources NO-SOURCE
:geode-old-versions:testClasses UP-TO-DATE
:geode-old-versions:checkMissedTests NO-SOURCE
:geode-old-versions:spotlessJavaCheck
:geode-old-versions:spotlessCheck
:geode-old-versions:test NO-SOURCE

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

[Spring CI]

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

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





--
This message is automatically generated by Atlassian Bamboo

Re: Next release: 1.4.0

[Bruce Schuchardt]

I need to merge feature/GEODE-4192 to the release branch.  There is a 
Protobuf client/locator change that needs to be included in the release.



On 1/5/18 11:15 AM, Sean Goller wrote:

The release pipeline is up:
https://concourse.apachegeode-ci.info/teams/main/pipelines/release-1.4.0

-Sean.

On Fri, Jan 5, 2018 at 10:00 AM, Anthony Baker  wrote:


+1

It should be pretty easy to clone the current pipeline for the 1.4.0
release branch.

I’ll plan to update the Jenkins jobs to run the `build` and
`updateArchives` tasks since those still have value.

Anthony



On Jan 4, 2018, at 5:03 PM, Alexander Murmann 

wrote:

The Concourse pipeline seems much more reliable at this point and the
pipelines should be providing equivalent test coverage. Given that, are
there any reasons to not deprecate Jenkins?

On Thu, Jan 4, 2018 at 4:55 PM, Jason Huynh  wrote:


Hi Swapnil,

GEODE-4140 was just marked for 1.4.  I think part of GEODE-4140 should

be

fixed because the process.ClusterConfigurationNotAvailableException

should

probably be reinstated.  If others don't think it's needed then feel

free

to remove the fix tag.

-Jason

On Thu, Jan 4, 2018 at 4:38 PM Dan Smith  wrote:


Our process up to this point has been to not ship until the jenkins

builds

on the release branch pass. We've been experimenting with concourse in
parallel with jenkins, but the jenkins builds on develop at least are

still

pretty messy. How are we going to ship this release? Should both be
passing?

-Dan

On Thu, Jan 4, 2018 at 4:23 PM, Swapnil Bawaskar 
have been addressed, I went ahead and created a release branch for

1.4.0.

Can someone please update the concourse pipelines to pick up this

release

branch?

Thanks!


On Tue, Nov 28, 2017 at 1:58 PM Swapnil Bawaskar <

sbawas...@pivotal.io

wrote:


Well, making sure that the JIRA's status is up-to-date and removing

the

1.4.0 version tag if the fix can wait for a later release.

On Tue, Nov 28, 2017 at 12:22 PM Michael William Dodge <

mdo...@pivotal.io>

wrote:


What sort of update? I know that GEODE-4010 has a PR that's awaiting
review and merge.

Sarge


On 28 Nov, 2017, at 10:03, Swapnil Bawaskar 

wrote:

Bump.  Any volunteers?  If not, I’ll do this.

Anthony



On Nov 22, 2017, at 1:48 PM, Anthony Baker 

wrote:

We released Geode 1.3.0 at the end of October.  Our next release

will

be

1.4.0.  Questions:

1) Who wants to volunteer as a release manager?
2) What do we want to include in the release?
3) When do we want to do this?

IMO, let's should shoot for an early Dec release.

Anthony

Build failed in Jenkins: Geode-release-flaky #49

[Apache Jenkins Server]

See 

--
[...truncated 143.51 KB...]
:geode-assembly:docs
:geode-assembly:gfshDepsJar
:geode-client-protocol:javadoc
:geode-client-protocol:javadocJar
:geode-client-protocol:sourcesJar
:geode-client-protocol:signArchives SKIPPED
:geode-common:javadocJar
:geode-common:sourcesJar
:geode-common:signArchives SKIPPED
:geode-connectors:jar
:geode-connectors:javadoc
:geode-connectors:javadocJar
:geode-connectors:sourcesJar
:geode-connectors:signArchives SKIPPED
:geode-core:javadocJar
:geode-core:raJar
:geode-core:jcaJar
:geode-core:sourcesJar
:geode-core:signArchives SKIPPED
:geode-core:webJar
:geode-cq:jar
:geode-cq:javadoc
:geode-cq:javadocJar
:geode-cq:sourcesJar
:geode-cq:signArchives SKIPPED
:geode-json:javadocJar
:geode-json:sourcesJar
:geode-json:signArchives SKIPPED
:geode-lucene:jar
:geode-lucene:javadoc
:geode-lucene:javadocJar
:geode-lucene:sourcesJar
:geode-lucene:signArchives SKIPPED
:geode-old-client-support:jar
:geode-old-client-support:javadoc
:geode-old-client-support:javadocJar
:geode-old-client-support:sourcesJar
:geode-old-client-support:signArchives SKIPPED
:geode-protobuf:jar
:geode-protobuf-messages:javadoc
:geode-protobuf:javadoc
:geode-protobuf:javadocJar
:geode-protobuf:sourcesJar
:geode-protobuf:signArchives SKIPPED
:geode-protobuf-messages:javadocJar
:geode-protobuf-messages:sourcesJar
:geode-protobuf-messages:signArchives SKIPPED
:geode-protobuf-messages:zip
:geode-pulse:javadoc
:geode-pulse:javadocJar
:geode-pulse:sourcesJar
:geode-pulse:war
:geode-pulse:signArchives SKIPPED
:geode-rebalancer:jar
:geode-rebalancer:javadoc
:geode-rebalancer:javadocJar
:geode-rebalancer:sourcesJar
:geode-rebalancer:signArchives SKIPPED
:geode-wan:jar
:geode-wan:javadoc
:geode-wan:javadocJar
:geode-wan:sourcesJar
:geode-wan:signArchives SKIPPED
:geode-web:javadoc NO-SOURCE
:geode-web:javadocJar
:geode-web:sourcesJar
:geode-web:war
:geode-web:signArchives SKIPPED
:geode-web-api:javadoc
:geode-web-api:javadocJar
:geode-web-api:sourcesJar
:geode-web-api:war
:geode-web-api:signArchives SKIPPED
:geode-assembly:installDist
:geode-pulse:jar
:geode-assembly:compileTestJava
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core-uberjar/1.6.3/cargo-core-uberjar-1.6.3.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core/1.6.3/cargo-core-1.6.3.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/codehaus-cargo/1.6.3/codehaus-cargo-1.6.3.pom
Download 
https://repo1.maven.org/maven2/commons-discovery/commons-discovery/0.5/commons-discovery-0.5.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core-uberjar/1.6.3/cargo-core-uberjar-1.6.3.jar
Download 
https://repo1.maven.org/maven2/commons-discovery/commons-discovery/0.5/commons-discovery-0.5.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.
Note: Recompile with -Xlint:unchecked for details.
:geode-assembly:processTestResources
:geode-assembly:testClasses
:geode-assembly:flakyTest

org.apache.geode.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest
 > testVersionTitleForStartServerAndLocator FAILED
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at 
org.apache.geode.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.readPid(LauncherLifecycleCommandsDUnitTest.java:195)
at 
org.apache.geode.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.waitForGemFireProcessToStop(LauncherLifecycleCommandsDUnitTest.java:260)
at 
org.apache.geode.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.stopServer(LauncherLifecycleCommandsDUnitTest.java:237)
at 
org.apache.geode.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.testVersionTitleForStartServerAndLocator(LauncherLifecycleCommandsDUnitTest.java:450)

16 tests completed, 1 failed
:geode-assembly:flakyTest FAILED
:geode-benchmarks:compileTestJava NO-SOURCE
:geode-benchmarks:processTestResources NO-SOURCE
:geode-benchmarks:testClasses UP-TO-DATE
:geode-benchmarks:flakyTest NO-SOURCE
:geode-client-protocol:compileTestJava NO-SOURCE
:geode-client-protocol:processTestResources NO-SOURCE
:geode-client-protocol:testClasses UP-TO-DATE
:geode-client-protocol:flakyTest NO-SOURCE
:geode-common:compileTestJava
:geode-common:processTestResources NO-SOURCE
:geode-common:testClasses
:geode-common:flakyTest
: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:flakyTest NO-SOURCE
:geode-connectors:compileTestJavaNote: Some input 

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

[apachegeodeci]

Pipeline results can be found at:

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

[DISCUSS] Benchmarks module package structure

[Nick Reich]

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.

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

[apachegeodeci]

Pipeline results can be found at:

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

Re: Next release: 1.4.0

[Sean Goller]

The release pipeline is up:
https://concourse.apachegeode-ci.info/teams/main/pipelines/release-1.4.0

-Sean.

On Fri, Jan 5, 2018 at 10:00 AM, Anthony Baker  wrote:

> +1
>
> It should be pretty easy to clone the current pipeline for the 1.4.0
> release branch.
>
> I’ll plan to update the Jenkins jobs to run the `build` and
> `updateArchives` tasks since those still have value.
>
> Anthony
>
>
> > On Jan 4, 2018, at 5:03 PM, Alexander Murmann 
> wrote:
> >
> > The Concourse pipeline seems much more reliable at this point and the
> > pipelines should be providing equivalent test coverage. Given that, are
> > there any reasons to not deprecate Jenkins?
> >
> > On Thu, Jan 4, 2018 at 4:55 PM, Jason Huynh  wrote:
> >
> >> Hi Swapnil,
> >>
> >> GEODE-4140 was just marked for 1.4.  I think part of GEODE-4140 should
> be
> >> fixed because the process.ClusterConfigurationNotAvailableException
> should
> >> probably be reinstated.  If others don't think it's needed then feel
> free
> >> to remove the fix tag.
> >>
> >> -Jason
> >>
> >> On Thu, Jan 4, 2018 at 4:38 PM Dan Smith  wrote:
> >>
> >>> Our process up to this point has been to not ship until the jenkins
> >> builds
> >>> on the release branch pass. We've been experimenting with concourse in
> >>> parallel with jenkins, but the jenkins builds on develop at least are
> >> still
> >>> pretty messy. How are we going to ship this release? Should both be
> >>> passing?
> >>>
> >>> -Dan
> >>>
> >>> On Thu, Jan 4, 2018 at 4:23 PM, Swapnil Bawaskar  >
> >>> wrote:
> >>>
>  Since all the issues tagged for 1.4.0 release
>    rapidView=92=GEODE=planning=
>  GEODE-3688=visible=12341842>
>  have been addressed, I went ahead and created a release branch for
> >> 1.4.0.
> 
>  Can someone please update the concourse pipelines to pick up this
> >> release
>  branch?
> 
>  Thanks!
> 
> 
>  On Tue, Nov 28, 2017 at 1:58 PM Swapnil Bawaskar <
> sbawas...@pivotal.io
> >>>
>  wrote:
> 
> > Well, making sure that the JIRA's status is up-to-date and removing
> >> the
> > 1.4.0 version tag if the fix can wait for a later release.
> >
> > On Tue, Nov 28, 2017 at 12:22 PM Michael William Dodge <
>  mdo...@pivotal.io>
> > wrote:
> >
> >> What sort of update? I know that GEODE-4010 has a PR that's awaiting
> >> review and merge.
> >>
> >> Sarge
> >>
> >>> On 28 Nov, 2017, at 10:03, Swapnil Bawaskar  >>>
> >> wrote:
> >>>
> >>> I would like to volunteer as a release manager.
> >>> Currently there are 14 issues that are marked for 1.4.0. If you
> >> are
> >> working
> >>> on any of these, can you please update the JIRA?
> >>>
> >> https://issues.apache.org/jira/secure/RapidBoard.jspa?
>  rapidView=92=GEODE=planning=
>  GEODE-3688=visible=12341842
> >>>
> >>> Thanks!
> >>>
> >>> On Tue, Nov 28, 2017 at 9:42 AM Anthony Baker 
> >> wrote:
> >>>
>  Bump.  Any volunteers?  If not, I’ll do this.
> 
>  Anthony
> 
> 
> > On Nov 22, 2017, at 1:48 PM, Anthony Baker 
>  wrote:
> >
> > We released Geode 1.3.0 at the end of October.  Our next release
>  will
> >> be
>  1.4.0.  Questions:
> >
> > 1) Who wants to volunteer as a release manager?
> > 2) What do we want to include in the release?
> > 3) When do we want to do this?
> >
> > IMO, let's should shoot for an early Dec release.
> >
> > Anthony
> >
> 
> 
> >>
> >>
> 
> >>>
> >>
>
>

Re: Next release: 1.4.0

[Jason Huynh]

Hi Anil,

Thanks, I'll take a look at that, I added that test a little while ago..

On Fri, Jan 5, 2018 at 10:13 AM Anilkumar Gingade 
wrote:

> I see :rat failing on Jenkins...
>
> The last run: https://builds.apache.org/job/Geode-release/100/console
>
> All test reports at
> /home/jenkins/jenkins-slave/workspace/Geode-release/build/reports/combined
>
> FAILURE: Build failed with an exception.
>
> * What went wrong:
> Execution failed for task ':rat'.
> > Found 1 files with unapproved/unknown licenses. See
> file:/home/jenkins/jenkins-slave/workspace/Geode-release/build/reports/rat/rat-report.txt
>
> *** Error:
>
> Unapproved licenses:
>
> /home/jenkins/jenkins-slave/workspace/Geode-release/geode-core/src/test/resources/org/apache/geode/cache/execute/FunctionAdapterJUnitTest.serializedFunctionAdapterWithDifferentSerialVersionUID
>
>
> -Anil.
>
>
>
> On Fri, Jan 5, 2018 at 10:00 AM, Anthony Baker  wrote:
>
> > +1
> >
> > It should be pretty easy to clone the current pipeline for the 1.4.0
> > release branch.
> >
> > I’ll plan to update the Jenkins jobs to run the `build` and
> > `updateArchives` tasks since those still have value.
> >
> > Anthony
> >
> >
> > > On Jan 4, 2018, at 5:03 PM, Alexander Murmann 
> > wrote:
> > >
> > > The Concourse pipeline seems much more reliable at this point and the
> > > pipelines should be providing equivalent test coverage. Given that, are
> > > there any reasons to not deprecate Jenkins?
> > >
> > > On Thu, Jan 4, 2018 at 4:55 PM, Jason Huynh  wrote:
> > >
> > >> Hi Swapnil,
> > >>
> > >> GEODE-4140 was just marked for 1.4.  I think part of GEODE-4140 should
> > be
> > >> fixed because the process.ClusterConfigurationNotAvailableException
> > should
> > >> probably be reinstated.  If others don't think it's needed then feel
> > free
> > >> to remove the fix tag.
> > >>
> > >> -Jason
> > >>
> > >> On Thu, Jan 4, 2018 at 4:38 PM Dan Smith  wrote:
> > >>
> > >>> Our process up to this point has been to not ship until the jenkins
> > >> builds
> > >>> on the release branch pass. We've been experimenting with concourse
> in
> > >>> parallel with jenkins, but the jenkins builds on develop at least are
> > >> still
> > >>> pretty messy. How are we going to ship this release? Should both be
> > >>> passing?
> > >>>
> > >>> -Dan
> > >>>
> > >>> On Thu, Jan 4, 2018 at 4:23 PM, Swapnil Bawaskar <
> sbawas...@pivotal.io
> > >
> > >>> wrote:
> > >>>
> >  Since all the issues tagged for 1.4.0 release
> >   >  rapidView=92=GEODE=planning=
> >  GEODE-3688=visible=12341842>
> >  have been addressed, I went ahead and created a release branch for
> > >> 1.4.0.
> > 
> >  Can someone please update the concourse pipelines to pick up this
> > >> release
> >  branch?
> > 
> >  Thanks!
> > 
> > 
> >  On Tue, Nov 28, 2017 at 1:58 PM Swapnil Bawaskar <
> > sbawas...@pivotal.io
> > >>>
> >  wrote:
> > 
> > > Well, making sure that the JIRA's status is up-to-date and removing
> > >> the
> > > 1.4.0 version tag if the fix can wait for a later release.
> > >
> > > On Tue, Nov 28, 2017 at 12:22 PM Michael William Dodge <
> >  mdo...@pivotal.io>
> > > wrote:
> > >
> > >> What sort of update? I know that GEODE-4010 has a PR that's
> awaiting
> > >> review and merge.
> > >>
> > >> Sarge
> > >>
> > >>> On 28 Nov, 2017, at 10:03, Swapnil Bawaskar <
> sbawas...@pivotal.io
> > >>>
> > >> wrote:
> > >>>
> > >>> I would like to volunteer as a release manager.
> > >>> Currently there are 14 issues that are marked for 1.4.0. If you
> > >> are
> > >> working
> > >>> on any of these, can you please update the JIRA?
> > >>>
> > >> https://issues.apache.org/jira/secure/RapidBoard.jspa?
> >  rapidView=92=GEODE=planning=
> >  GEODE-3688=visible=12341842
> > >>>
> > >>> Thanks!
> > >>>
> > >>> On Tue, Nov 28, 2017 at 9:42 AM Anthony Baker  >
> > >> wrote:
> > >>>
> >  Bump.  Any volunteers?  If not, I’ll do this.
> > 
> >  Anthony
> > 
> > 
> > > On Nov 22, 2017, at 1:48 PM, Anthony Baker 
> >  wrote:
> > >
> > > We released Geode 1.3.0 at the end of October.  Our next
> release
> >  will
> > >> be
> >  1.4.0.  Questions:
> > >
> > > 1) Who wants to volunteer as a release manager?
> > > 2) What do we want to include in the release?
> > > 3) When do we want to do this?
> > >
> > > IMO, let's should shoot for an early Dec release.
> > >
> > > Anthony
> > >
> > 
> > 
> > >>
> > >>
> > 
> > >>>
> > >>
> >
> >
>

Re: Next release: 1.4.0

[Anilkumar Gingade]

I see :rat failing on Jenkins...

The last run: https://builds.apache.org/job/Geode-release/100/console

All test reports at
/home/jenkins/jenkins-slave/workspace/Geode-release/build/reports/combined

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':rat'.
> Found 1 files with unapproved/unknown licenses. See 
> file:/home/jenkins/jenkins-slave/workspace/Geode-release/build/reports/rat/rat-report.txt

*** Error:

Unapproved licenses:
  
/home/jenkins/jenkins-slave/workspace/Geode-release/geode-core/src/test/resources/org/apache/geode/cache/execute/FunctionAdapterJUnitTest.serializedFunctionAdapterWithDifferentSerialVersionUID


-Anil.



On Fri, Jan 5, 2018 at 10:00 AM, Anthony Baker  wrote:

> +1
>
> It should be pretty easy to clone the current pipeline for the 1.4.0
> release branch.
>
> I’ll plan to update the Jenkins jobs to run the `build` and
> `updateArchives` tasks since those still have value.
>
> Anthony
>
>
> > On Jan 4, 2018, at 5:03 PM, Alexander Murmann 
> wrote:
> >
> > The Concourse pipeline seems much more reliable at this point and the
> > pipelines should be providing equivalent test coverage. Given that, are
> > there any reasons to not deprecate Jenkins?
> >
> > On Thu, Jan 4, 2018 at 4:55 PM, Jason Huynh  wrote:
> >
> >> Hi Swapnil,
> >>
> >> GEODE-4140 was just marked for 1.4.  I think part of GEODE-4140 should
> be
> >> fixed because the process.ClusterConfigurationNotAvailableException
> should
> >> probably be reinstated.  If others don't think it's needed then feel
> free
> >> to remove the fix tag.
> >>
> >> -Jason
> >>
> >> On Thu, Jan 4, 2018 at 4:38 PM Dan Smith  wrote:
> >>
> >>> Our process up to this point has been to not ship until the jenkins
> >> builds
> >>> on the release branch pass. We've been experimenting with concourse in
> >>> parallel with jenkins, but the jenkins builds on develop at least are
> >> still
> >>> pretty messy. How are we going to ship this release? Should both be
> >>> passing?
> >>>
> >>> -Dan
> >>>
> >>> On Thu, Jan 4, 2018 at 4:23 PM, Swapnil Bawaskar  >
> >>> wrote:
> >>>
>  Since all the issues tagged for 1.4.0 release
>    rapidView=92=GEODE=planning=
>  GEODE-3688=visible=12341842>
>  have been addressed, I went ahead and created a release branch for
> >> 1.4.0.
> 
>  Can someone please update the concourse pipelines to pick up this
> >> release
>  branch?
> 
>  Thanks!
> 
> 
>  On Tue, Nov 28, 2017 at 1:58 PM Swapnil Bawaskar <
> sbawas...@pivotal.io
> >>>
>  wrote:
> 
> > Well, making sure that the JIRA's status is up-to-date and removing
> >> the
> > 1.4.0 version tag if the fix can wait for a later release.
> >
> > On Tue, Nov 28, 2017 at 12:22 PM Michael William Dodge <
>  mdo...@pivotal.io>
> > wrote:
> >
> >> What sort of update? I know that GEODE-4010 has a PR that's awaiting
> >> review and merge.
> >>
> >> Sarge
> >>
> >>> On 28 Nov, 2017, at 10:03, Swapnil Bawaskar  >>>
> >> wrote:
> >>>
> >>> I would like to volunteer as a release manager.
> >>> Currently there are 14 issues that are marked for 1.4.0. If you
> >> are
> >> working
> >>> on any of these, can you please update the JIRA?
> >>>
> >> https://issues.apache.org/jira/secure/RapidBoard.jspa?
>  rapidView=92=GEODE=planning=
>  GEODE-3688=visible=12341842
> >>>
> >>> Thanks!
> >>>
> >>> On Tue, Nov 28, 2017 at 9:42 AM Anthony Baker 
> >> wrote:
> >>>
>  Bump.  Any volunteers?  If not, I’ll do this.
> 
>  Anthony
> 
> 
> > On Nov 22, 2017, at 1:48 PM, Anthony Baker 
>  wrote:
> >
> > We released Geode 1.3.0 at the end of October.  Our next release
>  will
> >> be
>  1.4.0.  Questions:
> >
> > 1) Who wants to volunteer as a release manager?
> > 2) What do we want to include in the release?
> > 3) When do we want to do this?
> >
> > IMO, let's should shoot for an early Dec release.
> >
> > Anthony
> >
> 
> 
> >>
> >>
> 
> >>>
> >>
>
>

Build failed in Jenkins: Geode-release #100

[Apache Jenkins Server]

See 

--
[...truncated 172.58 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.

Re: Next release: 1.4.0

[Anthony Baker]

+1

It should be pretty easy to clone the current pipeline for the 1.4.0 release 
branch.

I’ll plan to update the Jenkins jobs to run the `build` and `updateArchives` 
tasks since those still have value.

Anthony


> On Jan 4, 2018, at 5:03 PM, Alexander Murmann  wrote:
> 
> The Concourse pipeline seems much more reliable at this point and the
> pipelines should be providing equivalent test coverage. Given that, are
> there any reasons to not deprecate Jenkins?
> 
> On Thu, Jan 4, 2018 at 4:55 PM, Jason Huynh  wrote:
> 
>> Hi Swapnil,
>> 
>> GEODE-4140 was just marked for 1.4.  I think part of GEODE-4140 should be
>> fixed because the process.ClusterConfigurationNotAvailableException should
>> probably be reinstated.  If others don't think it's needed then feel free
>> to remove the fix tag.
>> 
>> -Jason
>> 
>> On Thu, Jan 4, 2018 at 4:38 PM Dan Smith  wrote:
>> 
>>> Our process up to this point has been to not ship until the jenkins
>> builds
>>> on the release branch pass. We've been experimenting with concourse in
>>> parallel with jenkins, but the jenkins builds on develop at least are
>> still
>>> pretty messy. How are we going to ship this release? Should both be
>>> passing?
>>> 
>>> -Dan
>>> 
>>> On Thu, Jan 4, 2018 at 4:23 PM, Swapnil Bawaskar 
>>> wrote:
>>> 
 Since all the issues tagged for 1.4.0 release
 
 have been addressed, I went ahead and created a release branch for
>> 1.4.0.
 
 Can someone please update the concourse pipelines to pick up this
>> release
 branch?
 
 Thanks!
 
 
 On Tue, Nov 28, 2017 at 1:58 PM Swapnil Bawaskar >> 
 wrote:
 
> Well, making sure that the JIRA's status is up-to-date and removing
>> the
> 1.4.0 version tag if the fix can wait for a later release.
> 
> On Tue, Nov 28, 2017 at 12:22 PM Michael William Dodge <
 mdo...@pivotal.io>
> wrote:
> 
>> What sort of update? I know that GEODE-4010 has a PR that's awaiting
>> review and merge.
>> 
>> Sarge
>> 
>>> On 28 Nov, 2017, at 10:03, Swapnil Bawaskar >> 
>> wrote:
>>> 
>>> I would like to volunteer as a release manager.
>>> Currently there are 14 issues that are marked for 1.4.0. If you
>> are
>> working
>>> on any of these, can you please update the JIRA?
>>> 
>> https://issues.apache.org/jira/secure/RapidBoard.jspa?
 rapidView=92=GEODE=planning=
 GEODE-3688=visible=12341842
>>> 
>>> Thanks!
>>> 
>>> On Tue, Nov 28, 2017 at 9:42 AM Anthony Baker 
>> wrote:
>>> 
 Bump.  Any volunteers?  If not, I’ll do this.
 
 Anthony
 
 
> On Nov 22, 2017, at 1:48 PM, Anthony Baker 
 wrote:
> 
> We released Geode 1.3.0 at the end of October.  Our next release
 will
>> be
 1.4.0.  Questions:
> 
> 1) Who wants to volunteer as a release manager?
> 2) What do we want to include in the release?
> 3) When do we want to do this?
> 
> IMO, let's should shoot for an early Dec release.
> 
> Anthony
> 
 
 
>> 
>> 
 
>>> 
>> 

Broken: apache/geode#5423 (develop - bb9ae49)

[Travis CI]

Build Update for apache/geode
-

Build: #5423
Status: Broken

Duration: 12 minutes and 22 seconds
Commit: bb9ae49 (develop)
Author: Bruce Schuchardt
Message: GEODE-4229 CI failure due to suspect string: "Locator socket was 
closed unexpectedly"

Removing error-level log message that was added during this cleanup
for GEODE-4176.

The server socket is closed as a matter of course in processing a
shutdown request, so we shouldn't consider this condition to be an
error.

View the changeset: 
https://github.com/apache/geode/compare/12307b8ca090...bb9ae49e0516

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/325505071?utm_source=email_medium=notification

--

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