Is there any way to enforce that with some kind of LGTM or spotless rule?
On 5/28/20, 12:46 PM, "Donal Evans" wrote:
I'm happy to say that as of about 5 minutes ago, there are no uses of
hardcoded "/" in region paths/names in the geode codebase, as all of them have
been replaced by the
In this specific case, how long has this issue been in the product? When did
we first see it? That would give me a lot more context in gauging the
“criticality” of this. Juan, can you share that information?
To Udo’s point, with every change we check in, we add some risk of instability
or at
To re-run tests it looks like the property is “forceTest”, so ./gradlew test
-PforceTest should do the trick.
For diagnosing the javadocs, this might come in handy:
A neat gradle trick I like to use to see which dependent tasks will get run is
the “-m” flag.
So something like "./gradlew -m
.
>>
>> I don't get any PowerMock warnings locally when I run unit tests.
>>
>> On Wed, Aug 7, 2019 at 9:50 AM Murtuza Boxwala
>> wrote:
>>
>>> Yea. I think it might be a red herring, because I am seeing those errors
>>> in every run, p
g 7, 2019, at 12:45 PM, Kirk Lund wrote:
>
> I don't know if the PowerMock warnings are related but that's the only
> thing interesting in the output before "timeout exceeded".
>
> On Wed, Aug 7, 2019 at 9:43 AM Murtuza Boxwala wrote:
>
>> How down know these warnin
How down know these warnings are related to the builds hanging. When I was on
CIO duty a couple days ago, I remember seeing this warning in a failing build,
but then I looked back at passing builds on saw this as well.
> On Aug 7, 2019, at 12:40 PM, Kirk Lund wrote:
>
> The build is broken
I am trying to deploy a "local" meta pipeline, but ran into a permissions issue
when trying to set or pause pipelines in apache geode. Can someone please add
me to the right group(s)?
In my ideal world, I compile and run tests with IntelliJ. IntelliJ is
constantly recompiling, so when you hit run, it’s usually just ready to run the
tests and the feedback loop feels much faster.
But, the “output path is not specified for modules” does seem to reappear
randomly, and
Problem:
Every time we make a put the code in BucketRegion.searchAndLock and
BucketRegion.removeAndNotifyKeys locks (synchronized) on a hash map, the
allKeysMap, to checkout the key to be modified and prevent anyone else from
updating at the same time. This area of the code gets a lot of
u 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,
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 wrote:
>
> Gotcha! Sounds good.
>
>> On Jun 20, 2019, at 4:35 PM, Dan Smith wrote:
>>
>> We don't have a
er this alternative: perhaps shorter method bodies obviate the
>> need for explicit final vars.
>>
>> Anthony
>>
>>
>>> On Jun 18, 2019, at 10:30 AM, Ernest Burghardt
>> wrote:
>>>
>>> +1 to auto-enforcement (if possible) po
final in Java does not guarantee immutability. It would be AWESOME if it did
but all it guarantees is that the variable cannot be reassigned. In most cases
the variable points to an object’s location (memory address), so you can still
call methods on it, e.g.
final var = new Foo();
Can I please have permissions to edit the Apache-Geode JIRA dashboard. My
username is mboxwala. I would like to be able to add new tickets, edit ticket,
assign tickets to myself…
Thanks,
Murtuza
14 matches
Mail list logo
