+1 for #2 On Mon, Oct 9, 2017 at 12:35 PM, Kirk Lund <kl...@pivotal.io> 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, 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 > > >
