You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Dan Smith <ds...@pivotal.io> on 2019/06/20 21:39:19 UTC
[DISCUSS] Add a test dependency to geode-core - ArchUnit
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
Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit
Posted by Dan Smith <ds...@pivotal.io>.
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 <cb...@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 <ud...@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 <ud...@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 <jb...@pivotal.io>
> > wrote:
> > >>>>
> > >>>> Gotcha! Sounds good.
> > >>>>
> > >>>>> On Jun 20, 2019, at 4:35 PM, Dan Smith <ds...@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 <
> jbarrett@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 <ds...@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 | cblack@pivotal.io
>
Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit
Posted by Charlie Black <cb...@pivotal.io>.
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 <ud...@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 <ud...@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 <jb...@pivotal.io>
> wrote:
> >>>>
> >>>> Gotcha! Sounds good.
> >>>>
> >>>>> On Jun 20, 2019, at 4:35 PM, Dan Smith <ds...@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 <jb...@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 <ds...@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 | cblack@pivotal.io
Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit
Posted by John Blum <jb...@pivotal.io>.
Of equal importance to uni-directional dependencies in a "modular" design
is, classes in package A should not refer directly to classes in package B
when A depends on B, or alternately, when module A depends on module B.
All interactions are only ever through interfaces and all implementations
are provided via an SPI, Factory, DI, etc, only. This makes B swappable
with another implementation similar to B that honors the contract of B.
Nearly all good Java framework are this way, e.g. Logging framework
facades. 1 interface for logging concerns, multiple implementations.
A superset of tangling is coupling and coupling is far worse than
tangling. Tangling, while discourages, can be manageable where as coupling
is much harder to uncouple.
Still, a huge +1 to uni-directional dependencies, which is often achieved
with organization/structuring and "strong" *Separation of Concerns*.
Cheers!
On Fri, Jun 21, 2019 at 1:04 PM Udo Kohlmeyer <ud...@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 <ud...@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 <jb...@pivotal.io>
> wrote:
> >>>>
> >>>> Gotcha! Sounds good.
> >>>>
> >>>>> On Jun 20, 2019, at 4:35 PM, Dan Smith <ds...@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 <jb...@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 <ds...@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
> >
>
--
-John
john.blum10101 (skype)
Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit
Posted by Udo Kohlmeyer <ud...@apache.org>.
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 <ud...@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 <jb...@pivotal.io> wrote:
>>>>
>>>> Gotcha! Sounds good.
>>>>
>>>>> On Jun 20, 2019, at 4:35 PM, Dan Smith <ds...@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 <jb...@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 <ds...@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
>
Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit
Posted by Murtuza Boxwala <mb...@pivotal.io>.
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 <ud...@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 <jb...@pivotal.io> wrote:
>>>
>>> Gotcha! Sounds good.
>>>
>>>> On Jun 20, 2019, at 4:35 PM, Dan Smith <ds...@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 <jb...@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 <ds...@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
>>>>>
Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit
Posted by Udo Kohlmeyer <ud...@apache.org>.
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 <jb...@pivotal.io> wrote:
>>
>> Gotcha! Sounds good.
>>
>>> On Jun 20, 2019, at 4:35 PM, Dan Smith <ds...@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 <jb...@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 <ds...@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
>>>>
Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit
Posted by Murtuza Boxwala <mb...@pivotal.io>.
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 <jb...@pivotal.io> wrote:
>
> Gotcha! Sounds good.
>
>> On Jun 20, 2019, at 4:35 PM, Dan Smith <ds...@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 <jb...@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 <ds...@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
>>>
>>>
Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit
Posted by Jacob Barrett <jb...@pivotal.io>.
Gotcha! Sounds good.
> On Jun 20, 2019, at 4:35 PM, Dan Smith <ds...@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 <jb...@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 <ds...@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
>>
>>
Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit
Posted by Michael Oleske <mo...@pivotal.io>.
Seems alright to me given the context that you're trying to separate code
into modules (and want to make sure you're not including packages you
shouldn't). Looking forward to see how the progress goes!
-michael
On Thu, Jun 20, 2019 at 4:35 PM Dan Smith <ds...@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 <jb...@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 <ds...@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
> >
> >
>
Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit
Posted by Dan Smith <ds...@pivotal.io>.
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 <jb...@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 <ds...@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
>
>
Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit
Posted by Jacob Barrett <jb...@pivotal.io>.
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 <ds...@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