Re: [Discuss] CliStrings

2017-10-20 Thread Jacob Barrett 
Exterminate!

> On Oct 20, 2017, at 3:47 PM, Kenneth Howe  wrote:
> 
> +1 for removing both CliStrings and LocalizedStrings
> 
>> On Oct 20, 2017, at 2:28 PM, Jinmei Liao  wrote:
>> 
>> +1 for removing it.
>> 
>>> On Fri, Oct 20, 2017 at 2:04 PM, Jared Stewart  wrote:
>>> 
>>> 
 On Oct 20, 2017, at 1:59 PM, Dan Smith  wrote:
 
 +1 for removing it.
 
 I do think it would be nice if we add localization in the future. But
 I don't really like the idea of leaving stuff in our code just in case
 we decide to implement a feature in the future - we might not even
 want what we left in there! In this case even with localization we
 might want to move these constants into their specific command classes
 anyway - the constant might just look up the localized string instead
 of being hardcoded.
 
 -Dan
>>> 
>>> Totally agree with this reasoning, I’m a firm believer in the YAGNI
>>> principle. (https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it <
>>> https://en.wikipedia.org/wiki/You_aren't_gonna_need_it>)
>>> 
>>> - Jared
>> 
>> 
>> 
>> 
>> -- 
>> Cheers
>> 
>> Jinmei
>

Native client examples

2017-10-20 Thread Dan Smith 
Hi,

I noticed some C# examples showed up in the geode-examples project. Awesome!

However I do think we should be compiling (and hopefully running!)
these examples so that they don't rot over time. Especially since I
believe we are still evolving the native API with breaking changes and
have not actually managed a release for the native code yet?

One option if it is too hard to automate the build of these things in
geode-examples is that we could put them into geode-native until we
actually release geode-native.

-Dan

Build failed in Jenkins: Geode-release #97

2017-10-20 Thread Apache Jenkins Server 
See 

--
[...truncated 7.80 MB...]
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.dispatch.FailureHandlingDispatch.dispatch(FailureHandlingDispatch.java:29)
at 
org.gradle.internal.dispatch.AsyncDispatch.dispatchMessages(AsyncDispatch.java:132)
at 
org.gradle.internal.dispatch.AsyncDispatch.access$000(AsyncDispatch.java:33)
at 
org.gradle.internal.dispatch.AsyncDispatch$1.run(AsyncDispatch.java:72)
at 
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
at 
org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.IOException: No space left on device
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:326)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
at 
org.codehaus.groovy.runtime.ResourceGroovyMethods.append(ResourceGroovyMethods.java:870)
at 
org.codehaus.groovy.runtime.ResourceGroovyMethods.leftShift(ResourceGroovyMethods.java:797)
at org.codehaus.groovy.runtime.dgm$970.invoke(Unknown Source)
at 
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:274)
at 
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:56)
at 
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
at 
test_767ee0xfb7ho44ms0v6sxeo93$_run_closure3$_closure20$_closure47$_closure48$_closure52.doCall(:246)
at sun.reflect.GeneratedMethodAccessor426.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
at 
org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1019)
at groovy.lang.Closure.call(Closure.java:426)
at 
org.gradle.listener.ClosureBackedMethodInvocationDispatch.dispatch(ClosureBackedMethodInvocationDispatch.java:40)
at 
org.gradle.listener.ClosureBackedMethodInvocationDispatch.dispatch(ClosureBackedMethodInvocationDispatch.java:25)
at 
org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:44)
... 31 more

org.apache.geode.test.dunit.internal.DUnitBlackboardDUnitTest > classMethod 
FAILED
java.lang.RuntimeException: Unable to launch dunit VMs

Caused by:
java.io.IOException: Cannot run program 
"/usr/local/asfpackages/java/jdk1.8.0_144/jre/bin/java" (in directory 
"dunit/locator"): error=2, No such file or directory

Caused by:
java.io.IOException: error=2, No such file or directory
Failed to notify test listener.
org.gradle.internal.event.ListenerNotificationException: Failed to notify test 
listener.
at 
org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:55)
at 
org.gradle.internal.event.BroadcastDispatch.dispatch(BroadcastDispatch.java:79)
at 
org.gradle.internal.event.BroadcastDispatch.dispatch(BroadcastDispatch.java:30)
at 
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy42.afterTest(Unknown Source)
at 
org.gradle.api.internal.tasks.testing.results.TestListenerAdapter.completed(TestListenerAdapter.java:50)
at sun.reflect.GeneratedMethodAccessor423.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at

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

2017-10-20 Thread Spring CI 

---
Spring Data GemFire > Nightly-ApacheGeode > #715 was successful.
---
Scheduled
2184 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Re: [Discuss] CliStrings

2017-10-20 Thread Kenneth Howe 
+1 for removing both CliStrings and LocalizedStrings

> On Oct 20, 2017, at 2:28 PM, Jinmei Liao  wrote:
> 
> +1 for removing it.
> 
> On Fri, Oct 20, 2017 at 2:04 PM, Jared Stewart  wrote:
> 
>> 
>>> On Oct 20, 2017, at 1:59 PM, Dan Smith  wrote:
>>> 
>>> +1 for removing it.
>>> 
>>> I do think it would be nice if we add localization in the future. But
>>> I don't really like the idea of leaving stuff in our code just in case
>>> we decide to implement a feature in the future - we might not even
>>> want what we left in there! In this case even with localization we
>>> might want to move these constants into their specific command classes
>>> anyway - the constant might just look up the localized string instead
>>> of being hardcoded.
>>> 
>>> -Dan
>> 
>> Totally agree with this reasoning, I’m a firm believer in the YAGNI
>> principle. (https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it <
>> https://en.wikipedia.org/wiki/You_aren't_gonna_need_it>)
>> 
>> - Jared
> 
> 
> 
> 
> -- 
> Cheers
> 
> Jinmei

Re: [Discuss] CliStrings

2017-10-20 Thread Jinmei Liao 
+1 for removing it.

On Fri, Oct 20, 2017 at 2:04 PM, Jared Stewart  wrote:

>
> > On Oct 20, 2017, at 1:59 PM, Dan Smith  wrote:
> >
> > +1 for removing it.
> >
> > I do think it would be nice if we add localization in the future. But
> > I don't really like the idea of leaving stuff in our code just in case
> > we decide to implement a feature in the future - we might not even
> > want what we left in there! In this case even with localization we
> > might want to move these constants into their specific command classes
> > anyway - the constant might just look up the localized string instead
> > of being hardcoded.
> >
> > -Dan
>
> Totally agree with this reasoning, I’m a firm believer in the YAGNI
> principle. (https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it <
> https://en.wikipedia.org/wiki/You_aren't_gonna_need_it>)
>
> - Jared




-- 
Cheers

Jinmei

Re: [VOTE] Apache Geode release - 1.3.0 RC3

2017-10-20 Thread Swapnil Bawaskar 
The commit sha in the vote request should be: 59f2a73d108101744ed7b2d88e8d1c
948d19781c
Sorry I forgot to update it for the latest release candidate.

Also, I ended up dropping and then re-adding all distributions
https://dist.apache.org/repos/dist/dev/geode/1.3.0.RC3
Can you please give this another try?

Thanks!

On Fri, Oct 20, 2017 at 9:30 PM Anthony Baker  wrote:

> I’m confused about which source tag we are voting on.
>
> ~/code/incubator-geode ((rel/v1.3.0.RC3))$ git tag -v rel/v1.3.0.RC3
> object 59f2a73d108101744ed7b2d88e8d1c948d19781c
> type commit
> tag rel/v1.3.0.RC3
> tagger Swapnil Bawaskar  1508355792 +0530
>
> Release candidate 3 for 1.3.0
> gpg: Signature made Wed Oct 18 12:43:21 2017 PDT
> gpg:using RSA key 8F8F2BCC18F902DB
> gpg: Good signature from "Swapnil Bawaskar " [full]
>
> This is different than the commit sha in the vote request.  Also, the
> source and binary distributions appear to have been generated from
> different sha’s?
>
> ~/working$ ./apache-geode-1.3.0/bin/gfsh version --full | grep Revision
> Source-Revision: 9e076738fc2ae40f95bd179b5c1624e664a28d61
>
> ~/working$
> ./apache-geode-1.3.0-src/geode-assembly/build/install/apache-geode/bin/gfsh
> version --full | grep Revision
> Source-Revision: 59f2a73d108101744ed7b2d88e8d1c948d19781c
>
> Voting -1 based on this discrepancy.
>
>
> Other notes:
> - builds from source
> - binary distribution works
> - geode-examples builds from source
> - no binaries in source distribution
> - we should update the geode-examples distribution filename to ‘tgz’ to
> match the geode distribution in the next release
>
> Anthony
>
> > On Oct 18, 2017, at 1:51 PM, Swapnil Bawaskar 
> wrote:
> >
> > This is the third release candidate for Apache Geode, version 1.3.0.
> > Thanks to all the community members for their contributions to this
> > release!
> >
> > *** Please download, test and vote by Monday, October 23, 0800 hrs
> > US Pacific. ***
> >
> > It fixes 376 issues. release notes can be found at:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420=12340669
> >
> > Note that we are voting upon the source tags:  rel/v1.3.0.RC3
> > https://github.com/apache/geode/tree/rel/v1.3.0.RC3
> > https://github.com/apache/geode-examples/tree/rel/v1.3.0.RC3
> >
> > Commit ID:
> > 9e076738fc2ae40f95bd179b5c1624e664a28d61 (geode)
> > 4ff8f8eafd0927888e711ee45d283ab07d345000   (geode-examples)
> >
> > Source and binary files:
> > https://dist.apache.org/repos/dist/dev/geode/1.3.0.RC3
> >
> > Maven staging repo:
> > https://repository.apache.org/content/repositories/orgapachegeode-1034
> >
> >
> > Geode's KEYS file containing PGP keys we use to sign the release:
> > https://github.com/apache/geode/blob/develop/KEYS
> >
> > Release Signed with Key: pub 4096R/18F902DB 2016-04-07
> > Fingerprint: E1B1 ABE3 4753 E7BA 8097 4285 8F8F 2BCC 18F9 02DB
>
>

Re: [Discuss] CliStrings

2017-10-20 Thread Jared Stewart 

> On Oct 20, 2017, at 1:59 PM, Dan Smith  wrote:
> 
> +1 for removing it.
> 
> I do think it would be nice if we add localization in the future. But
> I don't really like the idea of leaving stuff in our code just in case
> we decide to implement a feature in the future - we might not even
> want what we left in there! In this case even with localization we
> might want to move these constants into their specific command classes
> anyway - the constant might just look up the localized string instead
> of being hardcoded.
> 
> -Dan

Totally agree with this reasoning, I’m a firm believer in the YAGNI principle. 
(https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it 
)

- Jared

Re: [Discuss] CliStrings

2017-10-20 Thread Michael William Dodge 
+1 for removing it based on Dan's reasoning.

Sarge

> On 20 Oct, 2017, at 13:59, Dan Smith  wrote:
> 
> +1 for removing it.
> 
> I do think it would be nice if we add localization in the future. But
> I don't really like the idea of leaving stuff in our code just in case
> we decide to implement a feature in the future - we might not even
> want what we left in there! In this case even with localization we
> might want to move these constants into their specific command classes
> anyway - the constant might just look up the localized string instead
> of being hardcoded.
> 
> -Dan
> 
> On Fri, Oct 20, 2017 at 9:57 AM, Anilkumar Gingade  
> wrote:
>> As others mentioned this was done to support localization in the product;
>> this was driven from customer request; mainly from AMEA customers...
>> Now being open source; to build a wider community, Localization may become
>> a key requirement...Having a framework will help community to build on
>> that...
>> 
>> -Anil.
>> 
>> 
>> On Thu, Oct 19, 2017 at 4:32 PM, Mark Hanson  wrote:
>> 
>>> From my product background, maintaining a single file is often preferred
>>> for localization as mentioned by Mike, the big question, I would ask is how
>>> important is localization? If localization is important, then keeping a
>>> single or few file(s) will dramatically ease the localization process. So
>>> following Jared’s approach might make more work in the future, but it is
>>> certainly sound if there is no localization. This may also be an opportune
>>> time to review localization strategies within the code.
>>> 
>>> Thanks,
>>> Mark
 On Oct 19, 2017, at 3:28 PM, Bruce Schuchardt 
>>> wrote:
 
 +1 I thought we decided long ago to do this.  We also have
>>> LocalizedStrings.java and it looks like some folks are still adding new
>>> StringIDs to it as well.
 
 
 On 10/19/17 3:13 PM, Nick Reich wrote:
> +1 for moving those messages out of CliStrings if at all possible and
> placing them where they are used. In my experiences with those strings,
>>> I
> have rarely if ever seen them reused across classes, so they really
>>> should
> belong in the class they are used by.
> 
> On Thu, Oct 19, 2017 at 3:05 PM, Jared Stewart 
>>> wrote:
> 
>> I wanted to kick off a discussion about the usage of CliStrings.  For
>> those unfamiliar, it’s a java class that contains about ~3000 lines of
>> String constants and has a javadoc explaining that it is an attempt at
>>> i18n
>> localization.  Does anyone know if this localization is actually
>> implemented in practice?
>> 
>> If not, I would like suggest that we try to move away from this pattern
>> going forward.  We have ended up with many constants in CliStrings like
>> this:
>> CliStrings.CREATE_REGION__MSG__ONLY_ONE_OF_REGIONSHORTCUT_
>> AND_USEATTRIBUESFROM_CAN_BE_SPECIFIED
>> The constant is only used in CreateRegionCommand, so I would be
>>> happier to
>> see it as a member of CreateRegionCommand (where there would be no
>>> need for
>> the unwieldy "CREATE_REGION__MSG__” prefix) unless there is
>>> localization
>> being done which I am unaware of.
>> 
>> Thoughts?
>> 
>> Thanks,
>> Jared
 
>>> 
>>>

Re: [Discuss] CliStrings

2017-10-20 Thread Dan Smith 
+1 for removing it.

I do think it would be nice if we add localization in the future. But
I don't really like the idea of leaving stuff in our code just in case
we decide to implement a feature in the future - we might not even
want what we left in there! In this case even with localization we
might want to move these constants into their specific command classes
anyway - the constant might just look up the localized string instead
of being hardcoded.

-Dan

On Fri, Oct 20, 2017 at 9:57 AM, Anilkumar Gingade  wrote:
> As others mentioned this was done to support localization in the product;
> this was driven from customer request; mainly from AMEA customers...
> Now being open source; to build a wider community, Localization may become
> a key requirement...Having a framework will help community to build on
> that...
>
> -Anil.
>
>
> On Thu, Oct 19, 2017 at 4:32 PM, Mark Hanson  wrote:
>
>> From my product background, maintaining a single file is often preferred
>> for localization as mentioned by Mike, the big question, I would ask is how
>> important is localization? If localization is important, then keeping a
>> single or few file(s) will dramatically ease the localization process. So
>> following Jared’s approach might make more work in the future, but it is
>> certainly sound if there is no localization. This may also be an opportune
>> time to review localization strategies within the code.
>>
>> Thanks,
>> Mark
>> > On Oct 19, 2017, at 3:28 PM, Bruce Schuchardt 
>> wrote:
>> >
>> > +1 I thought we decided long ago to do this.  We also have
>> LocalizedStrings.java and it looks like some folks are still adding new
>> StringIDs to it as well.
>> >
>> >
>> > On 10/19/17 3:13 PM, Nick Reich wrote:
>> >> +1 for moving those messages out of CliStrings if at all possible and
>> >> placing them where they are used. In my experiences with those strings,
>> I
>> >> have rarely if ever seen them reused across classes, so they really
>> should
>> >> belong in the class they are used by.
>> >>
>> >> On Thu, Oct 19, 2017 at 3:05 PM, Jared Stewart 
>> wrote:
>> >>
>> >>> I wanted to kick off a discussion about the usage of CliStrings.  For
>> >>> those unfamiliar, it’s a java class that contains about ~3000 lines of
>> >>> String constants and has a javadoc explaining that it is an attempt at
>> i18n
>> >>> localization.  Does anyone know if this localization is actually
>> >>> implemented in practice?
>> >>>
>> >>> If not, I would like suggest that we try to move away from this pattern
>> >>> going forward.  We have ended up with many constants in CliStrings like
>> >>> this:
>> >>> CliStrings.CREATE_REGION__MSG__ONLY_ONE_OF_REGIONSHORTCUT_
>> >>> AND_USEATTRIBUESFROM_CAN_BE_SPECIFIED
>> >>> The constant is only used in CreateRegionCommand, so I would be
>> happier to
>> >>> see it as a member of CreateRegionCommand (where there would be no
>> need for
>> >>> the unwieldy "CREATE_REGION__MSG__” prefix) unless there is
>> localization
>> >>> being done which I am unaware of.
>> >>>
>> >>> Thoughts?
>> >>>
>> >>> Thanks,
>> >>> Jared
>> >
>>
>>

Failed: jinmeiliao/geode#50 (parseResult - 0c13b33)

2017-10-20 Thread Travis CI 
Build Update for jinmeiliao/geode
-

Build: #50
Status: Failed

Duration: 15 minutes and 15 seconds
Commit: 0c13b33 (parseResult)
Author: Jinmei Liao
Message: GEODE-1897: refactor GfshParseResult for easy access of converted 
option value

View the changeset: 
https://github.com/jinmeiliao/geode/compare/d2a942e8e502^...0c13b3357ae1

View the full build log and details: 
https://travis-ci.org/jinmeiliao/geode/builds/290582885?utm_source=email_medium=notification

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

Re: [Discuss] CliStrings

2017-10-20 Thread Anilkumar Gingade 
As others mentioned this was done to support localization in the product;
this was driven from customer request; mainly from AMEA customers...
Now being open source; to build a wider community, Localization may become
a key requirement...Having a framework will help community to build on
that...

-Anil.


On Thu, Oct 19, 2017 at 4:32 PM, Mark Hanson  wrote:

> From my product background, maintaining a single file is often preferred
> for localization as mentioned by Mike, the big question, I would ask is how
> important is localization? If localization is important, then keeping a
> single or few file(s) will dramatically ease the localization process. So
> following Jared’s approach might make more work in the future, but it is
> certainly sound if there is no localization. This may also be an opportune
> time to review localization strategies within the code.
>
> Thanks,
> Mark
> > On Oct 19, 2017, at 3:28 PM, Bruce Schuchardt 
> wrote:
> >
> > +1 I thought we decided long ago to do this.  We also have
> LocalizedStrings.java and it looks like some folks are still adding new
> StringIDs to it as well.
> >
> >
> > On 10/19/17 3:13 PM, Nick Reich wrote:
> >> +1 for moving those messages out of CliStrings if at all possible and
> >> placing them where they are used. In my experiences with those strings,
> I
> >> have rarely if ever seen them reused across classes, so they really
> should
> >> belong in the class they are used by.
> >>
> >> On Thu, Oct 19, 2017 at 3:05 PM, Jared Stewart 
> wrote:
> >>
> >>> I wanted to kick off a discussion about the usage of CliStrings.  For
> >>> those unfamiliar, it’s a java class that contains about ~3000 lines of
> >>> String constants and has a javadoc explaining that it is an attempt at
> i18n
> >>> localization.  Does anyone know if this localization is actually
> >>> implemented in practice?
> >>>
> >>> If not, I would like suggest that we try to move away from this pattern
> >>> going forward.  We have ended up with many constants in CliStrings like
> >>> this:
> >>> CliStrings.CREATE_REGION__MSG__ONLY_ONE_OF_REGIONSHORTCUT_
> >>> AND_USEATTRIBUESFROM_CAN_BE_SPECIFIED
> >>> The constant is only used in CreateRegionCommand, so I would be
> happier to
> >>> see it as a member of CreateRegionCommand (where there would be no
> need for
> >>> the unwieldy "CREATE_REGION__MSG__” prefix) unless there is
> localization
> >>> being done which I am unaware of.
> >>>
> >>> Thoughts?
> >>>
> >>> Thanks,
> >>> Jared
> >
>
>

Re: [Discuss] CliStrings

2017-10-20 Thread Kirk Lund 
CliStrings has nothing to do with localization. The original authors of
GFSH simply stored all GFSH strings as static final constants in that class.

As for LocalizedStrings, it was a non-standard way of doing localization
and was abandoned by the development team years ago because it's garbage.
There was a single developer a decade ago that added it and for some crazy
unknown reason decided to invent a new way to do something that was already
well-supported in Java.

LocalizedStrings has also not been used or kept up-to-date for several
years now. 90% or more of new strings visible to Users that were added over
the last 5+ years have been coded in place in instead of using
LocalizedStrings.

My vote is to remove both CliStrings and LocalizedStrings. If we decide
that Apache Geode should support localization then we should switch to
using Java Localization.

On Thu, Oct 19, 2017 at 4:32 PM, Mark Hanson  wrote:

> From my product background, maintaining a single file is often preferred
> for localization as mentioned by Mike, the big question, I would ask is how
> important is localization? If localization is important, then keeping a
> single or few file(s) will dramatically ease the localization process. So
> following Jared’s approach might make more work in the future, but it is
> certainly sound if there is no localization. This may also be an opportune
> time to review localization strategies within the code.
>
> Thanks,
> Mark
> > On Oct 19, 2017, at 3:28 PM, Bruce Schuchardt 
> wrote:
> >
> > +1 I thought we decided long ago to do this.  We also have
> LocalizedStrings.java and it looks like some folks are still adding new
> StringIDs to it as well.
> >
> >
> > On 10/19/17 3:13 PM, Nick Reich wrote:
> >> +1 for moving those messages out of CliStrings if at all possible and
> >> placing them where they are used. In my experiences with those strings,
> I
> >> have rarely if ever seen them reused across classes, so they really
> should
> >> belong in the class they are used by.
> >>
> >> On Thu, Oct 19, 2017 at 3:05 PM, Jared Stewart 
> wrote:
> >>
> >>> I wanted to kick off a discussion about the usage of CliStrings.  For
> >>> those unfamiliar, it’s a java class that contains about ~3000 lines of
> >>> String constants and has a javadoc explaining that it is an attempt at
> i18n
> >>> localization.  Does anyone know if this localization is actually
> >>> implemented in practice?
> >>>
> >>> If not, I would like suggest that we try to move away from this pattern
> >>> going forward.  We have ended up with many constants in CliStrings like
> >>> this:
> >>> CliStrings.CREATE_REGION__MSG__ONLY_ONE_OF_REGIONSHORTCUT_
> >>> AND_USEATTRIBUESFROM_CAN_BE_SPECIFIED
> >>> The constant is only used in CreateRegionCommand, so I would be
> happier to
> >>> see it as a member of CreateRegionCommand (where there would be no
> need for
> >>> the unwieldy "CREATE_REGION__MSG__” prefix) unless there is
> localization
> >>> being done which I am unaware of.
> >>>
> >>> Thoughts?
> >>>
> >>> Thanks,
> >>> Jared
> >
>
>

Re: [VOTE] Apache Geode release - 1.3.0 RC3

2017-10-20 Thread Anthony Baker 
I’m confused about which source tag we are voting on.

~/code/incubator-geode ((rel/v1.3.0.RC3))$ git tag -v rel/v1.3.0.RC3
object 59f2a73d108101744ed7b2d88e8d1c948d19781c
type commit
tag rel/v1.3.0.RC3
tagger Swapnil Bawaskar  1508355792 +0530

Release candidate 3 for 1.3.0
gpg: Signature made Wed Oct 18 12:43:21 2017 PDT
gpg:using RSA key 8F8F2BCC18F902DB
gpg: Good signature from "Swapnil Bawaskar " [full]

This is different than the commit sha in the vote request.  Also, the source 
and binary distributions appear to have been generated from different sha’s?

~/working$ ./apache-geode-1.3.0/bin/gfsh version --full | grep Revision
Source-Revision: 9e076738fc2ae40f95bd179b5c1624e664a28d61

~/working$ 
./apache-geode-1.3.0-src/geode-assembly/build/install/apache-geode/bin/gfsh 
version --full | grep Revision
Source-Revision: 59f2a73d108101744ed7b2d88e8d1c948d19781c

Voting -1 based on this discrepancy.


Other notes:
- builds from source
- binary distribution works
- geode-examples builds from source
- no binaries in source distribution
- we should update the geode-examples distribution filename to ‘tgz’ to match 
the geode distribution in the next release

Anthony

> On Oct 18, 2017, at 1:51 PM, Swapnil Bawaskar  wrote:
> 
> This is the third release candidate for Apache Geode, version 1.3.0.
> Thanks to all the community members for their contributions to this
> release!
> 
> *** Please download, test and vote by Monday, October 23, 0800 hrs
> US Pacific. ***
> 
> It fixes 376 issues. release notes can be found at:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420=12340669
> 
> Note that we are voting upon the source tags:  rel/v1.3.0.RC3
> https://github.com/apache/geode/tree/rel/v1.3.0.RC3
> https://github.com/apache/geode-examples/tree/rel/v1.3.0.RC3
> 
> Commit ID:
> 9e076738fc2ae40f95bd179b5c1624e664a28d61 (geode)
> 4ff8f8eafd0927888e711ee45d283ab07d345000   (geode-examples)
> 
> Source and binary files:
> https://dist.apache.org/repos/dist/dev/geode/1.3.0.RC3
> 
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachegeode-1034
> 
> 
> Geode's KEYS file containing PGP keys we use to sign the release:
> https://github.com/apache/geode/blob/develop/KEYS
> 
> Release Signed with Key: pub 4096R/18F902DB 2016-04-07
> Fingerprint: E1B1 ABE3 4753 E7BA 8097 4285 8F8F 2BCC 18F9 02DB

Build failed in Jenkins: Geode-nightly #990

2017-10-20 Thread Apache Jenkins Server 
See 


Changes:

[github] GEODE-3521: Allow region set operations to bootstrap a transaction.

[kohlmu-pivotal] GEODE-3739: Refactor protobuf authentication (#922)

[kohlmu-pivotal] GEODE-3864: Added protobuf message file archiving

[kohlmu-pivotal] GEODE-3864: Added protobuf message file archiving

[kirk.lund] GEODE-3068: fix alphabetical ordering

[kirk.lund] GEODE-3866: add integration tests for deprecated launchers

[kirk.lund] Change DeprecatedAgentLauncherIntegrationTest to use TemporaryFolder

[kirk.lund] Isolate new methods accepting workingDirectory to only require

[kirk.lund] Fix format with spotless

[kirk.lund] GEODE-3847: upgrade to AssertJ 3.8.0

[bschuchardt] Squashed commit of the following:

[github] GEODE-3719: Improve invocations of disk store backups (#853)

[jstewart] GEODE-3859: Simplify API for reading output from a GfshScript

[jstewart] GEODE-3830: Add more logging for GfshRule

[lhughesgodfrey] GEODE-3345: Refactor ClusterConfigurationDUnitTest to use test 
rules

[github] GEODE-3810: Incremented test timestamp by 1 in case it is the same as

--
[...truncated 19.12 MB...]
at 
io.netty.channel.epoll.EpollDomainSocketChannel$EpollDomainUnsafe.epollInReady(EpollDomainSocketChannel.java:140)
at 
io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:386)
at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:302)
at 
io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:877)
at 
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
at java.lang.Thread.run(Thread.java:748)
at 
com.github.dockerjava.netty.handler.HttpResponseHandler.channelRead0(HttpResponseHandler.java:103)
at 
com.github.dockerjava.netty.handler.HttpResponseHandler.channelRead0(HttpResponseHandler.java:33)
at 
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:350)
at 
io.netty.handler.logging.LoggingHandler.channelRead(LoggingHandler.java:233)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:350)
at 
io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:435)
at 
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293)
at 
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267)
at 
io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:250)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:350)
at 
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
at 
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
at 
io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:961)
at 
io.netty.channel.epoll.EpollDomainSocketChannel$EpollDomainUnsafe.epollInReady(EpollDomainSocketChannel.java:140)
at 
io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:386)
at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:302)
at 
io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:877)
at 
io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
at java.lang.Thread.run(Thread.java:748)
com.github.dockerjava.api.exception.NotFoundException: {"message":"No such 
image: apachegeode/geode-build:latest"}

at

Build failed in Jenkins: Geode-release #95

2017-10-20 Thread Apache Jenkins Server 
See 

--
[...truncated 149.96 KB...]
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at 
org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:113)
at 
org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:97)
at 
org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:103)
at 
org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest.startCluster(StopServerWithSecurityAcceptanceTest.java:113)
at 
org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest.cannotStopServerAsDataReaderOverJmx(StopServerWithSecurityAcceptanceTest.java:75)

org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest
 > canStopServerAsClusterAdminOverHttp FAILED
org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at 
org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:113)
at 
org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:97)
at 
org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:103)
at 
org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest.startCluster(StopServerWithSecurityAcceptanceTest.java:113)
at 
org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest.canStopServerAsClusterAdminOverHttp(StopServerWithSecurityAcceptanceTest.java:68)

org.apache.geode.management.internal.cli.shell.GfshExitCodeStatusCommandsTest > 
offlineStatusCommandShouldSucceedWhenConnected_server_dir FAILED
org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at 
org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitLoudly(GfshScript.java:131)
at 
org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:110)
at 
org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:97)
at 
org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:103)
at 
org.apache.geode.management.internal.cli.shell.GfshExitCodeStatusCommandsTest$TestConfiguration.startNecessaryMembers(GfshExitCodeStatusCommandsTest.java:397)
at 
org.apache.geode.management.internal.cli.shell.GfshExitCodeStatusCommandsTest.offlineStatusCommandShouldSucceedWhenConnected_server_dir(GfshExitCodeStatusCommandsTest.java:208)

org.apache.geode.management.internal.cli.shell.GfshExitCodeStatusCommandsTest > 
offlineStatusCommandShouldSucceedWhenConnected_server_pid FAILED
org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at 
org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:113)
at 
org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:97)
at 
org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:103)
at 
org.apache.geode.management.internal.cli.shell.GfshExitCodeStatusCommandsTest.executeScriptWithExpectedExitCode(GfshExitCodeStatusCommandsTest.java:368)
at 
org.apache.geode.management.internal.cli.shell.GfshExitCodeStatusCommandsTest.offlineStatusCommandShouldSucceedWhenConnected_server_pid(GfshExitCodeStatusCommandsTest.java:231)

org.apache.geode.management.internal.cli.shell.GfshExitCodeStatusCommandsTest > 
onlineStatusCommandShouldSucceedWhenConnected_locator_host_and_port FAILED
org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)