geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Udo Kohlmeyer <>
Subject Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit
Date Fri, 21 Jun 2019 20:03:59 GMT
Thank you for the response...

#1 - But isn't cyclical package dependent code not a smell and practice, 
whilst at the same time and uni-directional dependency is preferred.

Soo... I think I see the benefit to be more, that ArchUnit allows the 
untangling of code into a modular way WITHOUT a big bang approach of 
moving the code into modules and then having to be concerned about the 
fallout. But also it allows for the managing of package dependencies 
WITHOUT breaking the code out into different separate modules.

I really like ArchUnit :).. We should prioritize adoption :)


On 6/21/19 12:48, Murtuza Boxwala wrote:
> Two things come to mind:
> 1) uni-directional dependency
> Packages can be dependent on each other, because the classes inside of them can use each
other. e.g.	let’s say package A has class A1 and class A2 and package B has class B1 and
B2.  A1 can depend on B1, and B2 can depend on A2. Hence, the packages are dependent on each
> Modules can only have uni-directional dependency. If Module A depends on Module B, then
no class in Module B can reference a class in Module A.  This prevents tangling, i.e. spaghetti
> 2) Incremental compilation
> This lack of tangling helps not only developers, but the compiler too.  In the packages
example above, if I change any of the classes, all the code has to get recompiled because
the dependency lines can go in any direction, and the compiler won’t attempt to optimize.
 In the modules case, if Module A changes, Module B will not recompile, because the dependency
guarantees that nothing about Module B could have been affected.
>> On Jun 21, 2019, at 2:14 PM, Udo Kohlmeyer <> wrote:
>> 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 <> wrote:
>>>> Gotcha! Sounds good.
>>>>> On Jun 20, 2019, at 4:35 PM, Dan Smith <> wrote:
>>>>> We don't have a membership gradle module, just a package. We're adding
>>>>> 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
>>>>> 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 <>
>>>>>> Are you adding this dependency to just the membership module? I am
>>>>>> with that.
>>>>>>> On Jun 20, 2019, at 2:39 PM, Dan Smith <>
>>>>>>> Hi all,
>>>>>>> Bill, Ernie, and I would like to add a new (apache licensed)
>>>>>>> dependency to geode-core - 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
>>>>>>> that coming soon!).
>>>>>>> Does anyone have an issue with adding this test dependency?
>>>>>>> -Dan

View raw message