In that case, would it also make sense to move the existing GeodeGlossary class to org.apache.geode.common.internal, from its current location in org.apache.geode.util.internal?
On Sat, May 16, 2020 at 8:02 PM Jacob Barrett <jbarr...@pivotal.io> wrote: > I am fine as long as you make sure you use a package name that is going to > be Java 9 modules safe. Two modules cannot export the same package. So if > geode-commons is going to export org.apache.geode.util I think we will have > collisions. I suggest org.apache.geode.common. > > -Jake > > > > On May 16, 2020, at 1:23 PM, Donal Evans <doev...@pivotal.io> wrote: > > > > I've recently been working on a little side project to replace every use > of > > a hardcoded "/" character in region names/paths with a reference to the > > Region.SEPARATOR constant. I ran into some problems though, since the > > geode-management module needs to know about the separator character (in > the > > Region and Index classes) but does not have a dependency on geode-core, > > where the character is currently defined. > > > > Since the whole point of the exercise is to attempt to provide a single > > place where the region separator character is defined, pulling the > > definition down into a module upon which both geode-core and > > geode-management depend seems like the sensible choice, so I'm proposing > to > > create a GeodePublicGlossary class (name entirely up for change) in the > > geode-common/src/main/java/org/apache/geode/util/ package, moving the > > definition there, then deprecating the definitions in the Region > interface > > in geode-core. > > > > To preempt a possible question, there already exists a GeodeGlossary > class > > (which defines the GEMFIRE_PREFIX constant), but it's in an internal > > package, so isn't a suitable place to move the definition of the > currently > > user-visible region separator character. > > > > Any feedback or suggestions on this idea would be very welcome. > >
