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 <ukohlme...@pivotal.io> wrote: > @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 modularity or componentization? > Statistics can still have 99% of its implementation in the "internal" > package space, but surely we would still have a public interface that would > be exposed. > > To me it makes more sense to start thinking of modules and the > services/interfaces they expose, rather than is it internal to Geode. > > --Udo > > > On Mon, Oct 9, 2017 at 11:50 AM, Kirk Lund <kl...@apache.org> wrote: > > > 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 creating non-internal packages for things like > logging > > even if there are no classes in the non-internal package? > > > > On Mon, Oct 9, 2017 at 10:55 AM, Dan Smith <dsm...@pivotal.io> wrote: > > > > > +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 <u...@apache.org> wrote: > > > > > > > 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 difference to me and which one is the > preferred > > > > mechanism. I vote for approach 2, where the /*internal*/ package is > > > defined > > > > within the module/functional area. > > > > > > > > --Udo > > > > > > > > > > > > > -- > Kindest Regards > ----------------------------- > *Udo Kohlmeyer* | *Snr Solutions Architect* |*Pivotal* > *Mobile:* +61 409-279-160 | ukohlme...@pivotal.io > <http://www.gopivotal.com/> > www.pivotal.io >
