+1. Yes, the original intention was exactly as @VisibleForTesting.
On Mon, Dec 17, 2018 at 2:45 PM Galen O'Sullivan
wrote:
> Sounds good to me.
>
> On Mon, Dec 17, 2018 at 1:04 PM Owen Nichols wrote:
>
> > Sounds good, I would be happy to +1 a PR for this
> >
> > > On Dec 17, 2018, at 12:22
I agree that the Gradle is pathological in a lot of places. I've been
working on correcting that for the last several months. It's slow going
when you're restricted from breaking everything for a while. But it is
getting better, for what it's worth.
I can't tell from that stack-blob where you
Sounds good to me.
On Mon, Dec 17, 2018 at 1:04 PM Owen Nichols wrote:
> Sounds good, I would be happy to +1 a PR for this
>
> > On Dec 17, 2018, at 12:22 PM, Kirk Lund wrote:
> >
> > We have a custom annotation in geode-common called @TestingOnly:
> >
> >
Sounds good, I would be happy to +1 a PR for this
> On Dec 17, 2018, at 12:22 PM, Kirk Lund wrote:
>
> We have a custom annotation in geode-common called @TestingOnly:
>
> geode-common/src/main/java/org/apache/geode/annotations/TestingOnly.java
>
> This annotation was created while pairing
You're right. IntelliJ shouldn't be compiling these classes. However, the
real issue here is that our use of Gradle is so horribly unnatural that it
ends up confusing IntelliJ (and other tools). We should strive to NOT
confuse other tools by doing stupid stuff in Gradle.
You've seen my
We have a custom annotation in geode-common called @TestingOnly:
geode-common/src/main/java/org/apache/geode/annotations/TestingOnly.java
This annotation was created while pairing with Michael Feathers and the
intention was to annotate non-private constructors or methods that have a
widened
I don't understand our build or IntelliJ that well, but it seems weird to
me that these classes would be getting built at all since they're in the
resources section rather than java. I don't see compiled versions of these
classes in my geode directory. Perhaps it's an IntelliJ configuration issue?
IntelliJ just started failing to compile because we have two copies of
ExtendsFunctionAdapter.java. Apparently, IJ was happy enough to ignore
these duplicates for a month or so, but it's now fed up and will no longer
tolerate the duplication so it's failing with:
Error:(21, 8) java: duplicate
Hi team,
Can u please insight us regarding what is the best approach to verify whether
we are in Throttling? Is there any solution for this in the geode code?
If there is no such approach - we thought about implementing the above in our
server applicative code - in which we will use a remote
