I like the idea especially if its only for compile/test time and doesn't make it into the binary bits.
On Fri, Jun 21, 2019 at 1:04 PM Udo Kohlmeyer <u...@apache.org> wrote: > 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 > > > -- Charlie Black | cbl...@pivotal.io
