Re: Internal package name structure

2017-10-09 Thread Darrel Schneider
+1 for #2 On Mon, Oct 9, 2017 at 12:35 PM, Kirk Lund wrote: > Sounds good. > > Right now the User API for Statistics is in org.apache.geode (where it's > been since before my time) but we could deprecate it there and move it to > org.apache.geode.statistics. > > On Mon, Oct 9, 2017 at 12:28 PM,

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

2017-10-09 Thread Spring CI
--- Spring Data GemFire > Nightly-ApacheGeode > #704 was successful. --- Scheduled 2184 tests in total. https://build.spring.io/browse/SGF-NAG-704/ -- This

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

2017-10-09 Thread Apache Jenkins Server
See Changes: [jstewart] GEODE-3786: Suppress IOExceptions when reading process streams in [github] GEODE-3763: Refactor ListIndexCommandDUnitTest to use rules (#894) --

Re: Internal package name structure

2017-10-09 Thread Kirk Lund
Sounds good. Right now the User API for Statistics is in org.apache.geode (where it's been since before my time) but we could deprecate it there and move it to org.apache.geode.statistics. On Mon, Oct 9, 2017 at 12:28 PM, Udo Kohlmeyer wrote: > @Kirk, I believe that internal Geode moduels can b

Re: Internal package name structure

2017-10-09 Thread Udo Kohlmeyer
@Kirk, I believe that internal Geode moduels can be handled with approach #2, e.g "org.apache.geode.logging.internal"... I believe that we should think modules with public interfaces... even if the only consumers of those interfaces is another Geode module. How else would we achieve complete modul

Re: CacheListener invocations in bucket secondaries

2017-10-09 Thread Kirk Lund
Thanks Barry! On Mon, Oct 9, 2017 at 12:09 PM, Barry Oglesby wrote: > Kirk, > The system property is called: gemfire.BucketRegion. > alwaysFireLocalListeners > > -Dgemfire.BucketRegion.alwaysFireLocalListeners=true > > Thanks, > Barry Oglesby > > > On Mon, Oct 9, 2017 at 11:48 AM, Kirk Lund wro

Build failed in Jenkins: Geode-nightly #979

2017-10-09 Thread Apache Jenkins Server
See -- [...truncated 159.38 KB...] Note: Recompile with -Xlint:unchecked for details. :geode-cq:processTestResources :geode-cq:testClasses :geode-cq:checkMissedTests :geode-cq:spotlessJavaCh

Re: CacheListener invocations in bucket secondaries

2017-10-09 Thread Barry Oglesby
Kirk, The system property is called: gemfire.BucketRegion.alwaysFireLocalListeners -Dgemfire.BucketRegion.alwaysFireLocalListeners=true Thanks, Barry Oglesby On Mon, Oct 9, 2017 at 11:48 AM, Kirk Lund wrote: > Does anyone know what the system property is that enables CacheListener > invocatio

Re: Internal package name structure

2017-10-09 Thread Anilkumar Gingade
>> Do we want to start creating non-internal packages for things like logging >> even if there are no classes in the non-internal package? I think that should be fine...It shows that module doesn't have any external APIs. +1 for approach 2. -Anil. On Mon, Oct 9, 2017 at 11:50 AM, Kirk Lund wr

Re: Internal package name structure

2017-10-09 Thread Kirk Lund
The real reason we have both is because we have some internal components that don't have any corresponding User API (currently). For example, we have org.apache.geode.internal.logging and org.apache.geode.internal.statistics but neither of these have a non-internal package. Do we want to start cr

CacheListener invocations in bucket secondaries

2017-10-09 Thread Kirk Lund
Does anyone know what the system property is that enables CacheListener invocations in bucket secondaries? Or which class I should look in to find it? Thanks, Kirk

Re: Internal package name structure

2017-10-09 Thread Dan Smith
+1 for #2 We will need to be careful refactoring existing code if classes are sent over the wire. -Dan On Mon, Oct 9, 2017 at 10:36 AM, Udo Kohlmeyer wrote: > Hi there Geode devs, > > Whilst going through the code base I found that we have 2 differing > approaches of how we classify (or packag

Internal package name structure

2017-10-09 Thread Udo Kohlmeyer
Hi there Geode devs, Whilst going through the code base I found that we have 2 differing approaches of how we classify (or package structures) internal code. The first is /org.apache.geode.*INTERNAL*.module/ the other is /org.apache.geode.module.*INTERNAL*/. Can anyone explain the differenc