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/211

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

[apachegeodeci]

Pipeline results can be found at:

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

Re: [Discussion] Improving Spotless to be Even More Beautiful

[Galen O'Sullivan]

+1 to all of the above.

Will Spotless also reorder imports according to our canonical ordering?

On Mon, Mar 19, 2018 at 4:17 PM, Sai Boorlagadda 
wrote:

> +1
>
> On Mon, Mar 19, 2018 at 4:03 PM, Kirk Lund  wrote:
>
> > +1
> >
> > On Mon, Mar 19, 2018 at 2:51 PM, Patrick Rhomberg 
> > wrote:
> >
> > > Hello all!
> > >
> > >  I'm making another pass at patching up some of our smellier broken
> > > windows, to mix metaphors.  To that end, there are a few things I'd
> like
> > to
> > > add to spotless to more closely enforce adherence to our own style
> guide.
> > >
> > > I'd like to do the following to our spotless:
> > > - Bump spotless to the newest version, enabling some of the features
> > below
> > > - Have spotless only run spotless on files that have changed (Yay,
> > slightly
> > > faster builds!)
> > > - Have spotless perform the following spotless tasks:
> > > --- Remove unused imports.
> > > --- Prohibit wildcard imports, which may require manual expansion by
> the
> > > developer.  (But, in fairness, you shouldn't be using wildcard imports
> > > anyway.)
> > > --- Remove trivial javadoc stubs that are implicit in the method
> > signature
> > > (e.g., "@param p" with no description of what p actually is).
> > > --- Remove empty javadocs and block comments.
> > >
> > > This will again touch a great many files, so it should be targeted for
> > > immediately following a release, perhaps the impending 1.5.  It can
> > pretty
> > > easily be exploded into several commits across each subproject and task
> > for
> > > ease of review.
> > >
> > > Thoughts?
> > >
> > > Imagination is Change.
> > > ~Patrick Rhomberg
> > >
> >
>

Re: [Discussion] Improving Spotless to be Even More Beautiful

[Sai Boorlagadda]

+1

On Mon, Mar 19, 2018 at 4:03 PM, Kirk Lund  wrote:

> +1
>
> On Mon, Mar 19, 2018 at 2:51 PM, Patrick Rhomberg 
> wrote:
>
> > Hello all!
> >
> >  I'm making another pass at patching up some of our smellier broken
> > windows, to mix metaphors.  To that end, there are a few things I'd like
> to
> > add to spotless to more closely enforce adherence to our own style guide.
> >
> > I'd like to do the following to our spotless:
> > - Bump spotless to the newest version, enabling some of the features
> below
> > - Have spotless only run spotless on files that have changed (Yay,
> slightly
> > faster builds!)
> > - Have spotless perform the following spotless tasks:
> > --- Remove unused imports.
> > --- Prohibit wildcard imports, which may require manual expansion by the
> > developer.  (But, in fairness, you shouldn't be using wildcard imports
> > anyway.)
> > --- Remove trivial javadoc stubs that are implicit in the method
> signature
> > (e.g., "@param p" with no description of what p actually is).
> > --- Remove empty javadocs and block comments.
> >
> > This will again touch a great many files, so it should be targeted for
> > immediately following a release, perhaps the impending 1.5.  It can
> pretty
> > easily be exploded into several commits across each subproject and task
> for
> > ease of review.
> >
> > Thoughts?
> >
> > Imagination is Change.
> > ~Patrick Rhomberg
> >
>

Re: [Discussion] Improving Spotless to be Even More Beautiful

[Kirk Lund]

+1

On Mon, Mar 19, 2018 at 2:51 PM, Patrick Rhomberg 
wrote:

> Hello all!
>
>  I'm making another pass at patching up some of our smellier broken
> windows, to mix metaphors.  To that end, there are a few things I'd like to
> add to spotless to more closely enforce adherence to our own style guide.
>
> I'd like to do the following to our spotless:
> - Bump spotless to the newest version, enabling some of the features below
> - Have spotless only run spotless on files that have changed (Yay, slightly
> faster builds!)
> - Have spotless perform the following spotless tasks:
> --- Remove unused imports.
> --- Prohibit wildcard imports, which may require manual expansion by the
> developer.  (But, in fairness, you shouldn't be using wildcard imports
> anyway.)
> --- Remove trivial javadoc stubs that are implicit in the method signature
> (e.g., "@param p" with no description of what p actually is).
> --- Remove empty javadocs and block comments.
>
> This will again touch a great many files, so it should be targeted for
> immediately following a release, perhaps the impending 1.5.  It can pretty
> easily be exploded into several commits across each subproject and task for
> ease of review.
>
> Thoughts?
>
> Imagination is Change.
> ~Patrick Rhomberg
>

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #861 was successful.
---
Scheduled
2381 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Re: [Discussion] Improving Spotless to be Even More Beautiful

[Jared Stewart]

+1 to all of the above

On Mon, Mar 19, 2018 at 2:51 PM, Patrick Rhomberg 
wrote:

> Hello all!
>
>  I'm making another pass at patching up some of our smellier broken
> windows, to mix metaphors.  To that end, there are a few things I'd like to
> add to spotless to more closely enforce adherence to our own style guide.
>
> I'd like to do the following to our spotless:
> - Bump spotless to the newest version, enabling some of the features below
> - Have spotless only run spotless on files that have changed (Yay, slightly
> faster builds!)
> - Have spotless perform the following spotless tasks:
> --- Remove unused imports.
> --- Prohibit wildcard imports, which may require manual expansion by the
> developer.  (But, in fairness, you shouldn't be using wildcard imports
> anyway.)
> --- Remove trivial javadoc stubs that are implicit in the method signature
> (e.g., "@param p" with no description of what p actually is).
> --- Remove empty javadocs and block comments.
>
> This will again touch a great many files, so it should be targeted for
> immediately following a release, perhaps the impending 1.5.  It can pretty
> easily be exploded into several commits across each subproject and task for
> ease of review.
>
> Thoughts?
>
> Imagination is Change.
> ~Patrick Rhomberg
>

[Discussion] Improving Spotless to be Even More Beautiful

[Patrick Rhomberg]

Hello all!

 I'm making another pass at patching up some of our smellier broken
windows, to mix metaphors.  To that end, there are a few things I'd like to
add to spotless to more closely enforce adherence to our own style guide.

I'd like to do the following to our spotless:
- Bump spotless to the newest version, enabling some of the features below
- Have spotless only run spotless on files that have changed (Yay, slightly
faster builds!)
- Have spotless perform the following spotless tasks:
--- Remove unused imports.
--- Prohibit wildcard imports, which may require manual expansion by the
developer.  (But, in fairness, you shouldn't be using wildcard imports
anyway.)
--- Remove trivial javadoc stubs that are implicit in the method signature
(e.g., "@param p" with no description of what p actually is).
--- Remove empty javadocs and block comments.

This will again touch a great many files, so it should be targeted for
immediately following a release, perhaps the impending 1.5.  It can pretty
easily be exploded into several commits across each subproject and task for
ease of review.

Thoughts?

Imagination is Change.
~Patrick Rhomberg

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/329

Re: [Proposal] Gfsh Command Feature Flag Annotation

[Michael William Dodge]

I kind of like @Disabled instead.

Sarge

> On 19 Mar, 2018, at 11:58, Udo Kohlmeyer  wrote:
> 
> I wonder if this proposal could not be extended to the greater GEODE product. 
> As this feature flagging is also relevant to other parts of the system and 
> should maybe be consistently applied to all areas.
> 
> Thoughts?
> 
> 
> On 3/19/18 11:46, Patrick Rhomberg wrote:
>> Hello, All
>> 
>>   I am interested in extending annotation functionality on our gfsh
>> commands, particularly with respect to feature-flagging commands that are
>> mutually-reliant or not yet feature complete.
>>   Please review the proposal [1] at your convenience.
>> 
>> Imagination is Change.
>> ~Patrick Rhomberg
>> 
>> [1]
>> https://cwiki.apache.org/confluence/display/GEODE/Proposal+for+Gfsh+Feature+Flag
>> 
> 

Re: [Proposal] Gfsh Command Feature Flag Annotation

[Udo Kohlmeyer]

I wonder if this proposal could not be extended to the greater GEODE 
product. As this feature flagging is also relevant to other parts of the 
system and should maybe be consistently applied to all areas.


Thoughts?


On 3/19/18 11:46, Patrick Rhomberg wrote:

Hello, All

   I am interested in extending annotation functionality on our gfsh
commands, particularly with respect to feature-flagging commands that are
mutually-reliant or not yet feature complete.
   Please review the proposal [1] at your convenience.

Imagination is Change.
~Patrick Rhomberg

[1]
https://cwiki.apache.org/confluence/display/GEODE/Proposal+for+Gfsh+Feature+Flag

[Proposal] Gfsh Command Feature Flag Annotation

[Patrick Rhomberg]

Hello, All

  I am interested in extending annotation functionality on our gfsh
commands, particularly with respect to feature-flagging commands that are
mutually-reliant or not yet feature complete.
  Please review the proposal [1] at your convenience.

Imagination is Change.
~Patrick Rhomberg

[1]
https://cwiki.apache.org/confluence/display/GEODE/Proposal+for+Gfsh+Feature+Flag

Re: Disabling DistributedRestoreSystemPropertiesTest for now

[Kirk Lund]

Thanks Jens! I was searching for the cause on Friday but couldn't find it.

Looks like any static usage of ClusterStartupRule ends up launching DUnit
VMs. Gradle JUnit class loads (but does not instantiate) *Test.java. The
tests that have public static ClusterStartupRules result in ClusterStartupRule
being instantiated and the constructor contains
"DUnitLauncher.launchIfNeeded();" so we're launching DUnit VMs in both the
UnitTest and IntegrationTest targets.

I'm going to assign GEODE-4885 to myself and try to move
"DUnitLauncher.launchIfNeeded();"
from the constructor to the before on ClusterStartupRule.

On Sun, Mar 18, 2018 at 3:02 PM, Jens Deppe  wrote:

> It appears that DistributedRestoreSystemPropertiesTest is intermittently
> failing and breaking the build.
>
> My initial analysis shows that the use of *categories* results in *all*
> test classes being instantiated and some of those instantiations end up
> launching DUnit VMs as a result of static or parameterized declarations.
> This results in a false/positive situation
> causing DistributedRestoreSystemPropertiesTest to fail intermittently.
>
> I think I've pinpointed the classes causing the situation and listed them
> in the Jira. https://issues.apache.org/jira/browse/GEODE-4885.
>
> For now I've disabled the test to get builds going again.
>
> --Jens
>