CI failure

[Yossi Reginiano]

Hi,

For some reason the CI that was triggered after I committed my changes failed 
on the following -

error: cannot find symbol
  @ConfigAttributeGetter(name = THREAD_MONITOR_AUTO_ENABLED)
^

This symbol is well defined under - ConfigurationProperties
Also I did not make any changes there since my last commit in which CI was 
successful
Locally CI is working fine

Pull - Thread Monitoring Mechanism GEODE-5142 #1868
https://travis-ci.org/apache/geode/builds/376793484?utm_source=github_status&utm_medium=notification

Thanks,
Yossi Reginiano

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

Geode Build Changes Incoming -- Take care during merging!

[Patrick Rhomberg]

Hello, all, from your friendly neighborhood spotless-purveyor.

  With PR#1926, wildcard imports will be prohibited by spotless in
accordance with our style guide.
  As a gradle change, this presents the higher-than-typical possibility
that a PR with a green precheckin and successful build could fail in the
pipeline after merging.  Developers are encouraged to make sure they are
not using wildcard imports and to build a merged branch locally before
proceeding with the Squash And Merge available on GitHub.
  Thanks and happy coding!

Imagination is Change.
~Patrick Rhomberg

[1] https://github.com/apache/geode/pull/1926

Re: CI failure

[Dan Smith]

Hi Yossi,

Well, this one is confusing! Your branch builds fine for me too.

BUT, travis is not building your branch. It actually builds a *merge* of
your branch with develop. Which I guess the travis-ci people thought was
cool, but makes things really confusing in cases like this.

Your code doesn't compile when it's merged with develop because on develop
someone changed the imports in DistributionConfig. It used to be "import
static org.apache.geode.distributed.ConfigurationProperties.*;" which
included THREAD_MONITOR_AUTO_ENABLED, but now it's an explicit list of
imports.

Anyway, to fix this mess, just merge your changes with the latest develop,
fix the imports, and update your PR. Sorry about that.

-Dan

On Wed, May 9, 2018 at 5:16 AM, Yossi Reginiano 
wrote:

> Hi,
>
> For some reason the CI that was triggered after I committed my changes
> failed on the following -
>
> error: cannot find symbol
>   @ConfigAttributeGetter(name = THREAD_MONITOR_AUTO_ENABLED)
> ^
>
> This symbol is well defined under - ConfigurationProperties
> Also I did not make any changes there since my last commit in which CI was
> successful
> Locally CI is working fine
>
> Pull - Thread Monitoring Mechanism GEODE-5142 #1868
> https://travis-ci.org/apache/geode/builds/376793484?utm_
> source=github_status&utm_medium=notification
>
> Thanks,
> Yossi Reginiano
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at https://www.amdocs.com/about/email-disclaimer <
> https://www.amdocs.com/about/email-disclaimer>
>

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

[apachegeodeci]

Pipeline results can be found at:

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

[Proposal] Publicizing Extension et al for future consumption by the experimental Configuration Persistence Service (previously "Cluster Configuration Service")

[Patrick Rhomberg]

Hello, all!

  I was in the process of writing a Wiki entry [1] on my experience in
using the experimental cluster configuration API.  While making an explicit
distinction between the configuration class and any object(s) that
configuration class would create, I discovered that the Extension interface
is as yet internal.
  We have been iterating on making the configuration of the cluster in
general more programmatically  accessible.  See [2] for the ongoing
proposal, which will itself likely see much revision.
  The scope of this configuration API and associated refactoring has left
the underlying use of XML in place, to be removed in future efforts.  In
the interim, however, any developer wishing to create a persisted element
using our experimental configuration API will also need to implement these
XML aspects of their persisted objects.
  To formalize this, I would like to publicize the Extension interface, as
well as the related class ExtensionPoint.
  As iteration continues with respect to the configuration persistence
service, it is very likely that the current structure of ExtensionPoints on
the Region and Cache will be migrated to be handled by this or another
service.  However, the Extension interface will remain useful after this
fact.
  On the one hand, it feels awkward to publicize an API that we know will
not long survive the current iteration efforts.  On the other hand, it
feels fundamentally abhorrent to encourage a third-party developer to use
an internal API.
  Thoughts?

Imagination is Change.
~Patrick Rhomberg.


[1] https://cwiki.apache.org/confluence/display/GEODE/Extend
ing+Geode+-+Creating+Custom%2C+Persisted+Cache+Configuration+Elements
[2] https://cwiki.apache.org/confluence/pages/viewpage.
action?pageId=75975896

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

[apachegeodeci]

Pipeline results can be found at:

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

Re: [Proposal] Publicizing Extension et al for future consumption by the experimental Configuration Persistence Service (previously "Cluster Configuration Service")

[Jinmei Liao]

My vote would be to keep it as is:

1. It's going to be replaced anyway.
2. we've been living with this flaw(extension modules has to use an
internal api) since day one, might as well live with it for a little longer
before we replace it with a more preferred api.

but I can be convinced otherwise.



On Wed, May 9, 2018 at 11:27 AM, Patrick Rhomberg 
wrote:

> Hello, all!
>
>   I was in the process of writing a Wiki entry [1] on my experience in
> using the experimental cluster configuration API.  While making an explicit
> distinction between the configuration class and any object(s) that
> configuration class would create, I discovered that the Extension interface
> is as yet internal.
>   We have been iterating on making the configuration of the cluster in
> general more programmatically  accessible.  See [2] for the ongoing
> proposal, which will itself likely see much revision.
>   The scope of this configuration API and associated refactoring has left
> the underlying use of XML in place, to be removed in future efforts.  In
> the interim, however, any developer wishing to create a persisted element
> using our experimental configuration API will also need to implement these
> XML aspects of their persisted objects.
>   To formalize this, I would like to publicize the Extension interface, as
> well as the related class ExtensionPoint.
>   As iteration continues with respect to the configuration persistence
> service, it is very likely that the current structure of ExtensionPoints on
> the Region and Cache will be migrated to be handled by this or another
> service.  However, the Extension interface will remain useful after this
> fact.
>   On the one hand, it feels awkward to publicize an API that we know will
> not long survive the current iteration efforts.  On the other hand, it
> feels fundamentally abhorrent to encourage a third-party developer to use
> an internal API.
>   Thoughts?
>
> Imagination is Change.
> ~Patrick Rhomberg.
>
>
> [1] https://cwiki.apache.org/confluence/display/GEODE/Extend
> ing+Geode+-+Creating+Custom%2C+Persisted+Cache+Configuration+Elements
> [2] https://cwiki.apache.org/confluence/pages/viewpage.
> action?pageId=75975896
>



-- 
Cheers

Jinmei

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #912 was successful.
---
Scheduled
2387 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Request to edit / comment on Geode Confluence

[Addison Huddy]

Hi Geode Dev,

I would like to comment on a few of the Apache Geode proposals on
Confluence.  Can someone help me with the permissions?  I currently cannot
comment.

Thank you,
Addison