I know that I'm missing the benefit of physically moving the code from
the package into its own module.
Could you possibly explain to me what it is?
On 6/21/19 07:37, Murtuza Boxwala wrote:
I think that’s a really clever way to increment toward splitting geode-core
into more modules. I am excited to see what it looks like 👍
On Jun 20, 2019, at 7:45 PM, Jacob Barrett <jbarr...@pivotal.io> wrote:
Gotcha! Sounds good.
On Jun 20, 2019, at 4:35 PM, Dan Smith <dsm...@pivotal.io> wrote:
We don't have a membership gradle module, just a package. We're adding this
to geode-core.
For a little more context - we are thinking about refactoring membership
(and/or maybe some other pieces) into separate gradle modules - proposal
forthcoming! However, as a first step we need to untangle those pieces of
code from the rest of geode-core. Rather than creating some long lived
branch we can incrementally untangle the code a piece at a time, on
develop. Having a way to track progress and enforce the direction of
dependencies on the way to a separate gradle module will help with that.
-Dan
On Thu, Jun 20, 2019 at 4:23 PM Jacob Barrett <jbarr...@pivotal.io> wrote:
Are you adding this dependency to just the membership module? I am cool
with that.
On Jun 20, 2019, at 2:39 PM, Dan Smith <dsm...@pivotal.io> wrote:
Hi all,
Bill, Ernie, and I would like to add a new (apache licensed) test
dependency to geode-core - https://github.com/TNG/ArchUnit. This is a
tool
that lets you write tests that make assertions about the
interdependencies
of your code - for example enforcing that package A does not depend on
package B.
Initially we intend to add some tests about what parts of the system the
org.apache.geode.distributed.internal.membership package depends on, with
an eye towards making that code more independently testable (proposal on
that coming soon!).
Does anyone have an issue with adding this test dependency?
-Dan
