Re: PowerMock and mock ClassLoader

I added one comment to https://issues.apache.org/jira/browse/GEODE-6143 which lists every test file using PowerMockRunner. These will be the ones that take some work to remove PowerMock. I also added another comment which lists every test file importing something from PowerMockito but not actually

Re: PowerMock and mock ClassLoader

+1 to a spotless rule. Unless anyone objects, I’ll look into doing that after PowerMock is eliminated. Ryan On Tue, Dec 4, 2018 at 3:50 PM Helena Bales wrote: > Once we have refactored tests currently using PowerMock, it might be > prudent to introduce a spotless rule to prohibit the reintrodu

Re: PowerMock and mock ClassLoader

Once we have refactored tests currently using PowerMock, it might be prudent to introduce a spotless rule to prohibit the reintroduction of PowerMock. On Tue, Dec 4, 2018 at 3:32 PM Ryan McMahon wrote: > I am interested in contributing to this effort. I removed PowerMock usage > from one set of

Re: PowerMock and mock ClassLoader

I am interested in contributing to this effort. I removed PowerMock usage from one set of tests (GEODE-6052), and at that time I took a quick glance at other usages. I’ll assign GEODE-6143 to myself and see about removing the remaining usages. Ryan On Tue, Dec 4, 2018 at 3:08 PM Kirk Lund wrot

Re: PowerMock and mock ClassLoader

I filed GEODE-6143: PowerMock should not be used in Geode tests. We need everyone to stop using PowerMock in new tests. If anyone sees a PR attempting to use PowerMock please let the contributor know about GEODE-6143. The alternative is to refactor product code such that dependencies are passed in

Re: Using gradlew --tests runs test class twice

Oops, you're right. On Tue, Dec 4, 2018 at 11:03 AM Jacob Barrett wrote: > I don’t see how your output indicates the test is running twice. Is there > more output missing from the clip? Try added ‘—info’ to your Gradle command > to validate. > > > > On Dec 4, 2018, at 10:53 AM, Kirk Lund wrote:

Re: PowerMock and mock ClassLoader

+1 to removing PowerMock. Any situation that needs PowerMock needs refactoring more. -Dan On Tue, Dec 4, 2018 at 10:27 AM Kirk Lund wrote: > Anyone have any ideas which unit test is using PowerMock and is injecting a > mock ClassLoader? This keeps failing in my precheckin runs. I think we need

Re: Using gradlew --tests runs test class twice

I don’t see how your output indicates the test is running twice. Is there more output missing from the clip? Try added ‘—info’ to your Gradle command to validate. > On Dec 4, 2018, at 10:53 AM, Kirk Lund wrote: > > So, based on the output that I see from gradle when I execute this: > > $ ./g

Using gradlew --tests runs test class twice

So, based on the output that I see from gradle when I execute this: $ ./gradlew geode-core:integrationTest --tests AnalyzeSerializablesJUnitTest ...gradle apparently runs the test class twice. I say this because this is my output: 94% EXECUTING [1m 21s] geode-core:integrationTest > 3 tests comp

PowerMock and mock ClassLoader

Anyone have any ideas which unit test is using PowerMock and is injecting a mock ClassLoader? This keeps failing in my precheckin runs. I think we need to a) remove all uses of PowerMock and b) forbid its use going forward. 2018-12-04 18:11:36,258 Distributed system shutdown hook ERROR Could not r

Finalizing Java 9 Module Support Approach

All, Based on the experience we gained trying different iterations of the Java 9 Modules approaches I would like to recommend a path forward. I suggest we approve PR-2915, https://github.com/apache/geode/pull/2915 . The work done in this PR produces a

Re: Third Iteration of Java Modules Support

Like our our jars today a module is effectively part of your contract. That doesn’t mean we can’t create new modules/jars in the future that provide overlapping access to APIs. The uber jar in the first iteration was an example of this. Care just needs to be taken when defining dependencies on n

Re: Third Iteration of Java Modules Support

Jake, This is awesome! I do have a question, though: would releasing such a module info make it hard to improve upon later by giving the expectation of one set of modules? Thanks, Galen On Mon, Dec 3, 2018 at 4:44 PM Jacob Barrett wrote: > Yeah that would fix one of a dozen “leaked” internal p