Following up on this, it looks like there is consensus to go ahead and add ArchUnit. Thanks all!
-Dan On Fri, Jun 21, 2019 at 3:49 PM Charlie Black <cbl...@pivotal.io> wrote: > 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 >
