Re: Spring Boot for Apache Geode 1.0.0.M1 Released!

[Nicholas Vallely]

Congrats, this is awesome! I'll take a look later today and provide
feedback.

Nick

On Mon, Jun 25, 2018, 9:42 PM John Blum  wrote:

> Apache Geode Community-
>
> It is my please to announce the first milestone release of Spring Boot for
> Apache Geode, version 1.0.0.M1.
>
> See the official Spring Blog Post [1] for more details.
>
> Documentation [2] is available as are a couple of Examples [3].
>
> Feedback appreciated and welcomed.
>
> Much more to follow soon; stay tuned!
>
> Regards,
>
> --
> -John
>
> [1]
>
> https://spring.io/blog/2018/06/26/spring-boot-for-apache-geode-pivotal-gemfire-1-0-0-m1-released
> [2]
>
> https://spring.io/blog/2018/06/26/spring-boot-for-apache-geode-pivotal-gemfire-1-0-0-m1-released#documentation
> [3]
>
> https://spring.io/blog/2018/06/26/spring-boot-for-apache-geode-pivotal-gemfire-1-0-0-m1-released#examples
>

Re: Spring Boot for Apache Geode 1.0.0.M1 Released!

[Michael Stolz]

Great stuff John!

--
Mike Stolz
Principal Engineer - Gemfire Product Manager
Mobile: 631-835-4771

On Jun 26, 2018 12:42 AM, "John Blum"  wrote:

> Apache Geode Community-
>
> It is my please to announce the first milestone release of Spring Boot for
> Apache Geode, version 1.0.0.M1.
>
> See the official Spring Blog Post [1] for more details.
>
> Documentation [2] is available as are a couple of Examples [3].
>
> Feedback appreciated and welcomed.
>
> Much more to follow soon; stay tuned!
>
> Regards,
>
> --
> -John
>
> [1]
> https://spring.io/blog/2018/06/26/spring-boot-for-apache-
> geode-pivotal-gemfire-1-0-0-m1-released
> [2]
> https://spring.io/blog/2018/06/26/spring-boot-for-apache-
> geode-pivotal-gemfire-1-0-0-m1-released#documentation
> [3]
> https://spring.io/blog/2018/06/26/spring-boot-for-apache-
> geode-pivotal-gemfire-1-0-0-m1-released#examples
>

Re: Spring Boot for Apache Geode 1.0.0.M1 Released!

[Nilkanth Patel]

Great John, Congratulations!

Nilkanth Patel.

On Tue, Jun 26, 2018 at 7:20 PM, Michael Stolz  wrote:

> Great stuff John!
>
> --
> Mike Stolz
> Principal Engineer - Gemfire Product Manager
> Mobile: 631-835-4771
>
> On Jun 26, 2018 12:42 AM, "John Blum"  wrote:
>
> > Apache Geode Community-
> >
> > It is my please to announce the first milestone release of Spring Boot
> for
> > Apache Geode, version 1.0.0.M1.
> >
> > See the official Spring Blog Post [1] for more details.
> >
> > Documentation [2] is available as are a couple of Examples [3].
> >
> > Feedback appreciated and welcomed.
> >
> > Much more to follow soon; stay tuned!
> >
> > Regards,
> >
> > --
> > -John
> >
> > [1]
> > https://spring.io/blog/2018/06/26/spring-boot-for-apache-
> > geode-pivotal-gemfire-1-0-0-m1-released
> > [2]
> > https://spring.io/blog/2018/06/26/spring-boot-for-apache-
> > geode-pivotal-gemfire-1-0-0-m1-released#documentation
> > [3]
> > https://spring.io/blog/2018/06/26/spring-boot-for-apache-
> > geode-pivotal-gemfire-1-0-0-m1-released#examples
> >
>

DISCUSS: Refactor test source set for integrationTest and distributedTest

[Jacob Barrett]

I'd like to suggest that we refactor our current test source set, which
contains both unit, integration and distributed tests, into distinct source
sets, test, integrationTest, distributedTest. These source sets would
replace the use of the primary categories UnitTest, IntegrationTest and
DistributedTest.

The catalyst for this change is an issue that Gradle's test runner doesn't
pre-filter categories when launching tests, so if the tests are launched in
separate JVMs or Docker containers, like :distributeTest task, the cost of
spinning up those resources is realized only to immediately exit without
running any test for all test classes in the module. Switching to separate
source sets for each category would remove the need to filter on category
and only tests in the corresponding source set would get executed in their
external JVM or Docker container. An example of this issue is
geode-junit:distributedTest task, which forks all test classes in separate
JVMs but never actually runs any tests since there are no DistributedTest
tagged tests.

The secondary effect is a way too isolate dependencies in each of the
source sets. Unit tests in the test set would not have dependencies need
for integration tests or distributed test so that if you accidentally tried
to import classes from those frameworks you would get a compiler failure.
Likewise, integration tests would not include distributed test framework
dependencies. Any shared test classes like mock, dummies, fakes, etc. could
be shared in a commonTest source set, but would not contain any tests
itself.

The proposed structure would look like this:

test/ - only contains unit tests.
integrationTest/ - only contains integration style tests.
distributedTest/ - only includes DUnit based tests.
commonTest/ - includes commonly shared classes between each test category.
Does not contain any classes.

Thoughts?

-Jake

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #960 was SUCCESSFUL (with 2423 tests)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #960 was successful.
---
Scheduled
2425 tests in total.

https://build.spring.io/browse/SGF-NAG-960/





--
This message is automatically generated by Atlassian Bamboo

Re: DISCUSS: Refactor test source set for integrationTest and distributedTest

[Bruce Schuchardt]

This seems like a good idea to me.  I've never liked having the 
different types of tests all jumbled together.  OTOH I like to be able 
to run all MembershipTests using the category mechanism.  I would like 
to keep that ability, so I don't think we should do a wholesale removal 
of @Category.  You said "replace the use of primary categories", so I'm 
assuming you're not suggesting we do that.



On 6/26/18 3:36 PM, Jacob Barrett wrote:

I'd like to suggest that we refactor our current test source set, which
contains both unit, integration and distributed tests, into distinct source
sets, test, integrationTest, distributedTest. These source sets would
replace the use of the primary categories UnitTest, IntegrationTest and
DistributedTest.

The catalyst for this change is an issue that Gradle's test runner doesn't
pre-filter categories when launching tests, so if the tests are launched in
separate JVMs or Docker containers, like :distributeTest task, the cost of
spinning up those resources is realized only to immediately exit without
running any test for all test classes in the module. Switching to separate
source sets for each category would remove the need to filter on category
and only tests in the corresponding source set would get executed in their
external JVM or Docker container. An example of this issue is
geode-junit:distributedTest task, which forks all test classes in separate
JVMs but never actually runs any tests since there are no DistributedTest
tagged tests.

The secondary effect is a way too isolate dependencies in each of the
source sets. Unit tests in the test set would not have dependencies need
for integration tests or distributed test so that if you accidentally tried
to import classes from those frameworks you would get a compiler failure.
Likewise, integration tests would not include distributed test framework
dependencies. Any shared test classes like mock, dummies, fakes, etc. could
be shared in a commonTest source set, but would not contain any tests
itself.

The proposed structure would look like this:

test/ - only contains unit tests.
integrationTest/ - only contains integration style tests.
distributedTest/ - only includes DUnit based tests.
commonTest/ - includes commonly shared classes between each test category.
Does not contain any classes.

Thoughts?

-Jake

Re: DISCUSS: Refactor test source set for integrationTest and distributedTest

[Alexander Murmann]

Bruce, what use case do you see for the category annotation going forward?
Could we bring it back after we identified that we do in fact need it?

On Tue, Jun 26, 2018 at 4:13 PM, Bruce Schuchardt 
wrote:

> This seems like a good idea to me.  I've never liked having the different
> types of tests all jumbled together.  OTOH I like to be able to run all
> MembershipTests using the category mechanism.  I would like to keep that
> ability, so I don't think we should do a wholesale removal of @Category.
> You said "replace the use of primary categories", so I'm assuming you're
> not suggesting we do that.
>
>
>
> On 6/26/18 3:36 PM, Jacob Barrett wrote:
>
>> I'd like to suggest that we refactor our current test source set, which
>> contains both unit, integration and distributed tests, into distinct
>> source
>> sets, test, integrationTest, distributedTest. These source sets would
>> replace the use of the primary categories UnitTest, IntegrationTest and
>> DistributedTest.
>>
>> The catalyst for this change is an issue that Gradle's test runner doesn't
>> pre-filter categories when launching tests, so if the tests are launched
>> in
>> separate JVMs or Docker containers, like :distributeTest task, the cost of
>> spinning up those resources is realized only to immediately exit without
>> running any test for all test classes in the module. Switching to separate
>> source sets for each category would remove the need to filter on category
>> and only tests in the corresponding source set would get executed in their
>> external JVM or Docker container. An example of this issue is
>> geode-junit:distributedTest task, which forks all test classes in separate
>> JVMs but never actually runs any tests since there are no DistributedTest
>> tagged tests.
>>
>> The secondary effect is a way too isolate dependencies in each of the
>> source sets. Unit tests in the test set would not have dependencies need
>> for integration tests or distributed test so that if you accidentally
>> tried
>> to import classes from those frameworks you would get a compiler failure.
>> Likewise, integration tests would not include distributed test framework
>> dependencies. Any shared test classes like mock, dummies, fakes, etc.
>> could
>> be shared in a commonTest source set, but would not contain any tests
>> itself.
>>
>> The proposed structure would look like this:
>>
>> test/ - only contains unit tests.
>> integrationTest/ - only contains integration style tests.
>> distributedTest/ - only includes DUnit based tests.
>> commonTest/ - includes commonly shared classes between each test category.
>> Does not contain any classes.
>>
>> Thoughts?
>>
>> -Jake
>>
>>
>

Re: DISCUSS: Refactor test source set for integrationTest and distributedTest

[Dan Smith]

+1 for the suggested structure.

-Dan

On Tue, Jun 26, 2018 at 3:36 PM, Jacob Barrett  wrote:

> I'd like to suggest that we refactor our current test source set, which
> contains both unit, integration and distributed tests, into distinct source
> sets, test, integrationTest, distributedTest. These source sets would
> replace the use of the primary categories UnitTest, IntegrationTest and
> DistributedTest.
>
> The catalyst for this change is an issue that Gradle's test runner doesn't
> pre-filter categories when launching tests, so if the tests are launched in
> separate JVMs or Docker containers, like :distributeTest task, the cost of
> spinning up those resources is realized only to immediately exit without
> running any test for all test classes in the module. Switching to separate
> source sets for each category would remove the need to filter on category
> and only tests in the corresponding source set would get executed in their
> external JVM or Docker container. An example of this issue is
> geode-junit:distributedTest task, which forks all test classes in separate
> JVMs but never actually runs any tests since there are no DistributedTest
> tagged tests.
>
> The secondary effect is a way too isolate dependencies in each of the
> source sets. Unit tests in the test set would not have dependencies need
> for integration tests or distributed test so that if you accidentally tried
> to import classes from those frameworks you would get a compiler failure.
> Likewise, integration tests would not include distributed test framework
> dependencies. Any shared test classes like mock, dummies, fakes, etc. could
> be shared in a commonTest source set, but would not contain any tests
> itself.
>
> The proposed structure would look like this:
>
> test/ - only contains unit tests.
> integrationTest/ - only contains integration style tests.
> distributedTest/ - only includes DUnit based tests.
> commonTest/ - includes commonly shared classes between each test category.
> Does not contain any classes.
>
> Thoughts?
>
> -Jake
>

Re: DISCUSS: Refactor test source set for integrationTest and distributedTest

[Anthony Baker]

Sounds good, though I’m not entirely sure we need ‘commonTest/‘.  I guess we’ll 
find out :-)

Anthony


> On Jun 26, 2018, at 4:19 PM, Dan Smith  wrote:
> 
> +1 for the suggested structure.
> 
> -Dan
> 
> On Tue, Jun 26, 2018 at 3:36 PM, Jacob Barrett  wrote:
> 
>> I'd like to suggest that we refactor our current test source set, which
>> contains both unit, integration and distributed tests, into distinct source
>> sets, test, integrationTest, distributedTest. These source sets would
>> replace the use of the primary categories UnitTest, IntegrationTest and
>> DistributedTest.
>> 
>> The catalyst for this change is an issue that Gradle's test runner doesn't
>> pre-filter categories when launching tests, so if the tests are launched in
>> separate JVMs or Docker containers, like :distributeTest task, the cost of
>> spinning up those resources is realized only to immediately exit without
>> running any test for all test classes in the module. Switching to separate
>> source sets for each category would remove the need to filter on category
>> and only tests in the corresponding source set would get executed in their
>> external JVM or Docker container. An example of this issue is
>> geode-junit:distributedTest task, which forks all test classes in separate
>> JVMs but never actually runs any tests since there are no DistributedTest
>> tagged tests.
>> 
>> The secondary effect is a way too isolate dependencies in each of the
>> source sets. Unit tests in the test set would not have dependencies need
>> for integration tests or distributed test so that if you accidentally tried
>> to import classes from those frameworks you would get a compiler failure.
>> Likewise, integration tests would not include distributed test framework
>> dependencies. Any shared test classes like mock, dummies, fakes, etc. could
>> be shared in a commonTest source set, but would not contain any tests
>> itself.
>> 
>> The proposed structure would look like this:
>> 
>> test/ - only contains unit tests.
>> integrationTest/ - only contains integration style tests.
>> distributedTest/ - only includes DUnit based tests.
>> commonTest/ - includes commonly shared classes between each test category.
>> Does not contain any classes.
>> 
>> Thoughts?
>> 
>> -Jake
>> 

Re: DISCUSS: Refactor test source set for integrationTest and distributedTest

[Patrick Rhomberg]

I like the idea of good structure around our test-complexity @Category
layout.

@Alexander, not to speak for Bruce, but to my mind things like SecurityTest
/ WanTest / etc are orthogonal to the UnitTest / IntegrationTest /
DistributedTest / AcceptanceTest classification.  I like adding better
runtime and structure on the latter, but there's no real reason to
sacrifice the former labeling.

@Anthony, I'm pretty confident we'll need a commonTest.  Off the top of my
head, it'll need to host the startup rules, GfshRule, and the
SimpleSecurityManager.

On Tue, Jun 26, 2018 at 4:22 PM, Anthony Baker  wrote:

> Sounds good, though I’m not entirely sure we need ‘commonTest/‘.  I guess
> we’ll find out :-)
>
> Anthony
>
>
> > On Jun 26, 2018, at 4:19 PM, Dan Smith  wrote:
> >
> > +1 for the suggested structure.
> >
> > -Dan
> >
> > On Tue, Jun 26, 2018 at 3:36 PM, Jacob Barrett 
> wrote:
> >
> >> I'd like to suggest that we refactor our current test source set, which
> >> contains both unit, integration and distributed tests, into distinct
> source
> >> sets, test, integrationTest, distributedTest. These source sets would
> >> replace the use of the primary categories UnitTest, IntegrationTest and
> >> DistributedTest.
> >>
> >> The catalyst for this change is an issue that Gradle's test runner
> doesn't
> >> pre-filter categories when launching tests, so if the tests are
> launched in
> >> separate JVMs or Docker containers, like :distributeTest task, the cost
> of
> >> spinning up those resources is realized only to immediately exit without
> >> running any test for all test classes in the module. Switching to
> separate
> >> source sets for each category would remove the need to filter on
> category
> >> and only tests in the corresponding source set would get executed in
> their
> >> external JVM or Docker container. An example of this issue is
> >> geode-junit:distributedTest task, which forks all test classes in
> separate
> >> JVMs but never actually runs any tests since there are no
> DistributedTest
> >> tagged tests.
> >>
> >> The secondary effect is a way too isolate dependencies in each of the
> >> source sets. Unit tests in the test set would not have dependencies need
> >> for integration tests or distributed test so that if you accidentally
> tried
> >> to import classes from those frameworks you would get a compiler
> failure.
> >> Likewise, integration tests would not include distributed test framework
> >> dependencies. Any shared test classes like mock, dummies, fakes, etc.
> could
> >> be shared in a commonTest source set, but would not contain any tests
> >> itself.
> >>
> >> The proposed structure would look like this:
> >>
> >> test/ - only contains unit tests.
> >> integrationTest/ - only contains integration style tests.
> >> distributedTest/ - only includes DUnit based tests.
> >> commonTest/ - includes commonly shared classes between each test
> category.
> >> Does not contain any classes.
> >>
> >> Thoughts?
> >>
> >> -Jake
> >>
>
>

Re: DISCUSS: Refactor test source set for integrationTest and distributedTest

[Anilkumar Gingade]

+1 for restructuring.

-Anil.

On Tue, Jun 26, 2018 at 4:34 PM, Patrick Rhomberg 
wrote:

> I like the idea of good structure around our test-complexity @Category
> layout.
>
> @Alexander, not to speak for Bruce, but to my mind things like SecurityTest
> / WanTest / etc are orthogonal to the UnitTest / IntegrationTest /
> DistributedTest / AcceptanceTest classification.  I like adding better
> runtime and structure on the latter, but there's no real reason to
> sacrifice the former labeling.
>
> @Anthony, I'm pretty confident we'll need a commonTest.  Off the top of my
> head, it'll need to host the startup rules, GfshRule, and the
> SimpleSecurityManager.
>
> On Tue, Jun 26, 2018 at 4:22 PM, Anthony Baker  wrote:
>
> > Sounds good, though I’m not entirely sure we need ‘commonTest/‘.  I guess
> > we’ll find out :-)
> >
> > Anthony
> >
> >
> > > On Jun 26, 2018, at 4:19 PM, Dan Smith  wrote:
> > >
> > > +1 for the suggested structure.
> > >
> > > -Dan
> > >
> > > On Tue, Jun 26, 2018 at 3:36 PM, Jacob Barrett 
> > wrote:
> > >
> > >> I'd like to suggest that we refactor our current test source set,
> which
> > >> contains both unit, integration and distributed tests, into distinct
> > source
> > >> sets, test, integrationTest, distributedTest. These source sets would
> > >> replace the use of the primary categories UnitTest, IntegrationTest
> and
> > >> DistributedTest.
> > >>
> > >> The catalyst for this change is an issue that Gradle's test runner
> > doesn't
> > >> pre-filter categories when launching tests, so if the tests are
> > launched in
> > >> separate JVMs or Docker containers, like :distributeTest task, the
> cost
> > of
> > >> spinning up those resources is realized only to immediately exit
> without
> > >> running any test for all test classes in the module. Switching to
> > separate
> > >> source sets for each category would remove the need to filter on
> > category
> > >> and only tests in the corresponding source set would get executed in
> > their
> > >> external JVM or Docker container. An example of this issue is
> > >> geode-junit:distributedTest task, which forks all test classes in
> > separate
> > >> JVMs but never actually runs any tests since there are no
> > DistributedTest
> > >> tagged tests.
> > >>
> > >> The secondary effect is a way too isolate dependencies in each of the
> > >> source sets. Unit tests in the test set would not have dependencies
> need
> > >> for integration tests or distributed test so that if you accidentally
> > tried
> > >> to import classes from those frameworks you would get a compiler
> > failure.
> > >> Likewise, integration tests would not include distributed test
> framework
> > >> dependencies. Any shared test classes like mock, dummies, fakes, etc.
> > could
> > >> be shared in a commonTest source set, but would not contain any tests
> > >> itself.
> > >>
> > >> The proposed structure would look like this:
> > >>
> > >> test/ - only contains unit tests.
> > >> integrationTest/ - only contains integration style tests.
> > >> distributedTest/ - only includes DUnit based tests.
> > >> commonTest/ - includes commonly shared classes between each test
> > category.
> > >> Does not contain any classes.
> > >>
> > >> Thoughts?
> > >>
> > >> -Jake
> > >>
> >
> >
>

Re: DISCUSS: Refactor test source set for integrationTest and distributedTest

[Alexander Murmann]

@Patrick Those all sound like great use cases to me

+1 to new structure. So far this seems like a change with no downsides.

On Tue, Jun 26, 2018 at 4:46 PM, Anilkumar Gingade 
wrote:

> +1 for restructuring.
>
> -Anil.
>
> On Tue, Jun 26, 2018 at 4:34 PM, Patrick Rhomberg 
> wrote:
>
> > I like the idea of good structure around our test-complexity @Category
> > layout.
> >
> > @Alexander, not to speak for Bruce, but to my mind things like
> SecurityTest
> > / WanTest / etc are orthogonal to the UnitTest / IntegrationTest /
> > DistributedTest / AcceptanceTest classification.  I like adding better
> > runtime and structure on the latter, but there's no real reason to
> > sacrifice the former labeling.
> >
> > @Anthony, I'm pretty confident we'll need a commonTest.  Off the top of
> my
> > head, it'll need to host the startup rules, GfshRule, and the
> > SimpleSecurityManager.
> >
> > On Tue, Jun 26, 2018 at 4:22 PM, Anthony Baker 
> wrote:
> >
> > > Sounds good, though I’m not entirely sure we need ‘commonTest/‘.  I
> guess
> > > we’ll find out :-)
> > >
> > > Anthony
> > >
> > >
> > > > On Jun 26, 2018, at 4:19 PM, Dan Smith  wrote:
> > > >
> > > > +1 for the suggested structure.
> > > >
> > > > -Dan
> > > >
> > > > On Tue, Jun 26, 2018 at 3:36 PM, Jacob Barrett 
> > > wrote:
> > > >
> > > >> I'd like to suggest that we refactor our current test source set,
> > which
> > > >> contains both unit, integration and distributed tests, into distinct
> > > source
> > > >> sets, test, integrationTest, distributedTest. These source sets
> would
> > > >> replace the use of the primary categories UnitTest, IntegrationTest
> > and
> > > >> DistributedTest.
> > > >>
> > > >> The catalyst for this change is an issue that Gradle's test runner
> > > doesn't
> > > >> pre-filter categories when launching tests, so if the tests are
> > > launched in
> > > >> separate JVMs or Docker containers, like :distributeTest task, the
> > cost
> > > of
> > > >> spinning up those resources is realized only to immediately exit
> > without
> > > >> running any test for all test classes in the module. Switching to
> > > separate
> > > >> source sets for each category would remove the need to filter on
> > > category
> > > >> and only tests in the corresponding source set would get executed in
> > > their
> > > >> external JVM or Docker container. An example of this issue is
> > > >> geode-junit:distributedTest task, which forks all test classes in
> > > separate
> > > >> JVMs but never actually runs any tests since there are no
> > > DistributedTest
> > > >> tagged tests.
> > > >>
> > > >> The secondary effect is a way too isolate dependencies in each of
> the
> > > >> source sets. Unit tests in the test set would not have dependencies
> > need
> > > >> for integration tests or distributed test so that if you
> accidentally
> > > tried
> > > >> to import classes from those frameworks you would get a compiler
> > > failure.
> > > >> Likewise, integration tests would not include distributed test
> > framework
> > > >> dependencies. Any shared test classes like mock, dummies, fakes,
> etc.
> > > could
> > > >> be shared in a commonTest source set, but would not contain any
> tests
> > > >> itself.
> > > >>
> > > >> The proposed structure would look like this:
> > > >>
> > > >> test/ - only contains unit tests.
> > > >> integrationTest/ - only contains integration style tests.
> > > >> distributedTest/ - only includes DUnit based tests.
> > > >> commonTest/ - includes commonly shared classes between each test
> > > category.
> > > >> Does not contain any classes.
> > > >>
> > > >> Thoughts?
> > > >>
> > > >> -Jake
> > > >>
> > >
> > >
> >
>

Re: DISCUSS: Refactor test source set for integrationTest and distributedTest

[Kirk Lund]

+1 although I'm not sure I like "commonTest"

On Tue, Jun 26, 2018 at 3:36 PM, Jacob Barrett  wrote:

> I'd like to suggest that we refactor our current test source set, which
> contains both unit, integration and distributed tests, into distinct source
> sets, test, integrationTest, distributedTest. These source sets would
> replace the use of the primary categories UnitTest, IntegrationTest and
> DistributedTest.
>
> The catalyst for this change is an issue that Gradle's test runner doesn't
> pre-filter categories when launching tests, so if the tests are launched in
> separate JVMs or Docker containers, like :distributeTest task, the cost of
> spinning up those resources is realized only to immediately exit without
> running any test for all test classes in the module. Switching to separate
> source sets for each category would remove the need to filter on category
> and only tests in the corresponding source set would get executed in their
> external JVM or Docker container. An example of this issue is
> geode-junit:distributedTest task, which forks all test classes in separate
> JVMs but never actually runs any tests since there are no DistributedTest
> tagged tests.
>
> The secondary effect is a way too isolate dependencies in each of the
> source sets. Unit tests in the test set would not have dependencies need
> for integration tests or distributed test so that if you accidentally tried
> to import classes from those frameworks you would get a compiler failure.
> Likewise, integration tests would not include distributed test framework
> dependencies. Any shared test classes like mock, dummies, fakes, etc. could
> be shared in a commonTest source set, but would not contain any tests
> itself.
>
> The proposed structure would look like this:
>
> test/ - only contains unit tests.
> integrationTest/ - only contains integration style tests.
> distributedTest/ - only includes DUnit based tests.
> commonTest/ - includes commonly shared classes between each test category.
> Does not contain any classes.
>
> Thoughts?
>
> -Jake
>

Re: DISCUSS: Refactor test source set for integrationTest and distributedTest

[Jacob Barrett]

> On Jun 26, 2018, at 4:34 PM, Patrick Rhomberg  wrote:
> 
> @Anthony, I'm pretty confident we'll need a commonTest.  Off the top of my
> head, it'll need to host the startup rules, GfshRule, and the
> SimpleSecurityManager.

None of these examples would make sense in unit tests so probably not a good 
use for common. The original though was things like dummy domain objects, stuff 
shared by all 3 test type. Rules, and such should be in a separate project 
altogether and included as dependent of integration and distributed tests only. 

Re: DISCUSS: Refactor test source set for integrationTest and distributedTest

[Jacob Barrett]

> On Jun 26, 2018, at 5:34 PM, Kirk Lund  wrote:
> 
> +1 although I'm not sure I like "commonTest"

The choice of name or the concept of some common classes? I’m not sold on 
either myself but tossed it in there to quell issues that may arise from some 
shared classes between the Test types.

Re: DISCUSS: Refactor test source set for integrationTest and distributedTest

[Jacob Barrett]

> On Jun 26, 2018, at 4:13 PM, Bruce Schuchardt  wrote:
> 
> This seems like a good idea to me.  I've never liked having the different 
> types of tests all jumbled together.  OTOH I like to be able to run all 
> MembershipTests using the category mechanism.  I would like to keep that 
> ability, so I don't think we should do a wholesale removal of @Category.  You 
> said "replace the use of primary categories", so I'm assuming you're not 
> suggesting we do that.

Correct, just suggesting no primary category, unit , integration or 
distributed. The component classification is still acceptable.

Build failed in Jenkins: Geode-nightly #1237

[Apache Jenkins Server]

See 


Changes:

[bschuchardt] GEODE-1655: CI Failure in

--
[...truncated 26.66 KB...]
> Task :geode-assembly:assemble
> Task :extensions/session-testing-war:jar
> Task :geode-pulse:jar
> Task :geode-pulse:compileTestJava FROM-CACHE
> Task :geode-pulse:processTestResources
> Task :geode-pulse:testClasses
> Task :geode-assembly:compileTestJava FROM-CACHE
> Task :geode-assembly:processTestResources
> Task :geode-assembly:testClasses
> Task :geode-assembly:checkMissedTests
> Task :geode-assembly:spotlessJava
> Task :geode-assembly:spotlessJavaCheck
> Task :geode-assembly:spotlessCheck
> Task :geode-assembly:installDist
> Task :geode-assembly:test
> Task :geode-common:assemble
> Task :geode-common:compileTestJava FROM-CACHE
> Task :geode-common:processTestResources NO-SOURCE
> Task :geode-common:testClasses UP-TO-DATE
> Task :geode-common:checkMissedTests
> Task :geode-common:spotlessJava
> Task :geode-common:spotlessJavaCheck
> Task :geode-common:spotlessCheck
> Task :geode-common:test
> Task :geode-concurrency-test:javadoc FROM-CACHE
> Task :geode-concurrency-test:javadocJar
> Task :geode-concurrency-test:sourcesJar
> Task :geode-concurrency-test:signArchives SKIPPED
> Task :geode-concurrency-test:assemble
> Task :geode-concurrency-test:compileTestJava NO-SOURCE
> Task :geode-concurrency-test:processTestResources NO-SOURCE
> Task :geode-concurrency-test:testClasses UP-TO-DATE
> Task :geode-concurrency-test:checkMissedTests NO-SOURCE
> Task :geode-concurrency-test:spotlessJava
> Task :geode-concurrency-test:spotlessJavaCheck
> Task :geode-concurrency-test:spotlessCheck
> Task :geode-concurrency-test:test NO-SOURCE
> Task :geode-connectors:assemble
> Task :geode-connectors:compileTestJava FROM-CACHE
> Task :geode-connectors:processTestResources
> Task :geode-connectors:testClasses
> Task :geode-connectors:checkMissedTests
> Task :geode-connectors:spotlessJava
> Task :geode-connectors:spotlessJavaCheck
> Task :geode-connectors:spotlessCheck
> Task :geode-connectors:test
> Task :geode-core:assemble
> Task :geode-core:checkMissedTests
> Task :geode-core:spotlessJava
> Task :geode-core:spotlessJavaCheck
> Task :geode-core:spotlessCheck
> Task :geode-core:test
> Task :geode-cq:assemble
> Task :geode-cq:compileTestJava FROM-CACHE
> Task :geode-cq:processTestResources
> Task :geode-cq:testClasses
> Task :geode-cq:checkMissedTests
> Task :geode-cq:spotlessJava
> Task :geode-cq:spotlessJavaCheck
> Task :geode-cq:spotlessCheck
> Task :geode-cq:test
> Task :geode-experimental-driver:jar
> Task :geode-experimental-driver:javadoc FROM-CACHE
> Task :geode-experimental-driver:javadocJar
> Task :geode-experimental-driver:sourcesJar
> Task :geode-experimental-driver:signArchives SKIPPED
> Task :geode-experimental-driver:assemble
> Task :geode-experimental-driver:compileTestJava FROM-CACHE
> Task :geode-experimental-driver:processTestResources
> Task :geode-experimental-driver:testClasses
> Task :geode-experimental-driver:checkMissedTests
> Task :geode-experimental-driver:spotlessJava
> Task :geode-experimental-driver:spotlessJavaCheck
> Task :geode-experimental-driver:spotlessCheck
> Task :geode-experimental-driver:test
> Task :geode-json:assemble
> Task :geode-json:compileTestJava NO-SOURCE
> Task :geode-json:processTestResources
> Task :geode-json:testClasses
> Task :geode-json:checkMissedTests NO-SOURCE
> Task :geode-json:spotlessJava
> Task :geode-json:spotlessJavaCheck
> Task :geode-json:spotlessCheck
> Task :geode-json:test NO-SOURCE
> Task :geode-old-versions:javadoc NO-SOURCE
> Task :geode-junit:javadoc
> Task :geode-junit:javadocJar
> Task :geode-junit:sourcesJar
> Task :geode-junit:signArchives SKIPPED
> Task :geode-junit:assemble
> Task :geode-junit:compileTestJava FROM-CACHE
> Task :geode-junit:processTestResources
> Task :geode-junit:testClasses
> Task :geode-junit:checkMissedTests
> Task :geode-junit:spotlessJava
> Task :geode-junit:spotlessJavaCheck
> Task :geode-junit:spotlessCheck
> Task :geode-junit:test
> Task :geode-lucene:assemble
> Task :geode-lucene:compileTestJava FROM-CACHE
> Task :geode-lucene:processTestResources
> Task :geode-lucene:testClasses
> Task :geode-lucene:checkMissedTests
> Task :geode-lucene:spotlessJava
> Task :geode-lucene:spotlessJavaCheck
> Task :geode-lucene:spotlessCheck
> Task :geode-lucene:test
> Task :geode-old-client-support:assemble
> Task :geode-old-client-support:compileTestJava FROM-CACHE
> Task :geode-old-client-support:processTestResources NO-SOURCE
> Task :geode-old-client-support:testClasses UP-TO-DATE
> Task :geode-old-client-support:checkMissedTests
> Task :geode-old-client-support:spotlessJava
> Task :geode-old-client-support:spotlessJavaCheck
> Task :geode-old-client-support:spotlessCheck
> Task :geode-old-client-support:test
> Task :geode-old-versions:javadocJar
> Task :geode-old-versions:sourcesJar
> Task :geode-old-versions:signArchives SKIPPED