INFRA has added the status to the required list for merging PRs to
geode/develop. Thanks everyone.
On Fri, May 15, 2020 at 3:03 PM Robert Houghton
wrote:
> Please refer to https://issues.apache.org/jira/browse/INFRA-20270
>
> On Fri, May 15, 2020 at 2:58 PM Robert Houghton
> wrote:
>
>> Support
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
I'm fine with leaving the geode-management module out of this refactor and
leaving the SEPARATOR definition inside the Region interface in geode-code
if that's what's best to maintain proper modularity. However, looking at
the geode-management module, there is already a Region class which has
metho
The Region separator should not be user visible. In the past, we had tried
to remove needing this from the end-user or any other place. If we look
into its usage, it is mostly for sub-regions and we don't recommend much
use of this.
I was also wondering, its use by external or management modules ha
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 means that management module
will now start knowing about geode.
I su
