I vote that this separator is not moved into a common module. We should try to
stop leaking things out of “modules”. The only reason why we have a requirement
on the “/“ is to symbolize contextualization. I assume this came about because
of sub-regions.
I think we should rather aim to improve t
> On May 18, 2020, at 10:15 AM, Udo Kohlmeyer wrote:
>
> I was wondering. Why do we require to add this Region.SEPERATOR to be
> anywhere outside of Region.
>
> Geode-management was purposefully designed NOT to have a dependency on core.
> Creating a new dependency on a donor module, just m
code, but would it maybe not make more sense
> to just define that constant and maybe raise a JIRA so that we can address
> this "leakage" at a later stage?
>
> --Udo
> ____
> From: Jacob Barrett
> Sent: Saturday, May 16, 2020 11:02
e more sense
> to just define that constant and maybe raise a JIRA so that we can address
> this "leakage" at a later stage?
>
> --Udo
>
> From: Jacob Barrett
> Sent: Saturday, May 16, 2020 11:02 PM
> To: dev@geode.apache.org
> S
geode.apache.org
Subject: Re: [PROPOSAL] Move definition of Region separator character to
geode-common
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:
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