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 other.
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 <u...@apache.org> 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 <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
>>>>>
