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