geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Udo Kohlmeyer <ukohlme...@pivotal.io>
Subject Re: Internal package name structure
Date Mon, 09 Oct 2017 19:28:26 GMT
@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 <klund@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 <dsmith@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 <udo@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 | ukohlmeyer@pivotal.io
<http://www.gopivotal.com/>
www.pivotal.io

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message