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 :)
--Udo
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 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
