Versions Compared

Old Version 27

changes.mady.by.user Ryan McMahon

Saved on

compared with

New Version 28

changes.mady.by.user Bill Burcham

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

PlantUML
@startuml
"geode-core" --> geode-membership
"geode-core" --> geode-serialization
"geode-membership" --> geode-serialization
@enduml



Breaking circular dependencies


The membership code currently has a number of dependencies on other classes within geode core. We will break these dependencies in essentially two different ways:

...

Classes used to wrap the membership APIs or inject dependencies into membership will be put in the org.apache.geode.distributed.internal.membership.adapter package.

Delineating Interfaces

Not only does this RFC specify inter-subproject dependency constraints (between geode-core, geode-membership, geode-serialization), it goes further. Classes outside geode-membership may only see geode-membership interfaces defined in the (TBD) membership API package (see below). Other interfaces and classes defined by membership will be inaccessible outside of membership.

Gradle Subprojects First—Java Modules Someday

This RFC describes creation of (2) new Gradle subprojects (geode-membership, geode-serialization). It also specifies the the allowed (and disallowed) inter-subproject dependencies. Our intention is to lay the ground for eventual use of Java modules to enforce these dependency constraints.

geode-membership API

The geode-membership subproject will provide the following API to the rest of the system. We will enforce that other parts of the system can only interact with this API.

...