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.
