Probably. Unfortunately we haven’t been very good and cleaning these up and
moving forward with a Java modules plan. It’s gunna bite us.
> On May 16, 2020, at 8:08 PM, Donal Evans wrote:
>
> In that case, would it also make sense to move the existing GeodeGlossary
> class to org.apache.geode.c
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 wrote:
> I am fine as long as you make sure you use a package name that
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, 20
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
Regio
