date:20161104

Re: more spotless problems on Windows

2016-11-04 Thread Bruce Schuchardt

I don't believe we did #2

Le 11/4/2016 à 12:09 PM, Jared Stewart a écrit :

@Bruce

To be clear, are you saying you did both of the following?

1). Create a .gitattributes file with “ *test eol=lf” at the top level of Geode
2). Change ‘UNIX’ in build.gradle to ‘GIT_ATTRIBUTES'

On Nov 4, 2016, at 12:07 PM, Bruce Schuchardt wrote:

Udo and I tried that & it didn't work. Maybe you'll have better luck.

Le 11/4/2016 à 11:59 AM, Jared Stewart a écrit :

From the spotless devs:

Git is not a pure content store, it mucks with line endings. Regardless of what
you check-in, it will store your files with unix line endings in the repo.

Then, when you checkout, it will modify the line endings to suit your platform. Unless
you add a .gitattributes file to tell git "forget the platform, do what this file
says".

Remove lineEndings 'UNIX' in your build.gradle [Jared - we should put
‘GIT_ATTRIBUTES’ in its place], and add a .gitattributes file in your root
directory with the content * text eol=lf and your problem will be fixed.

On Nov 4, 2016, at 10:48 AM, Nabarun Nag wrote:

Thank you Jared. I wanted to confirm that this was not an isolated incident
specific to my machine.

Regards
Naba

On Fri, Nov 4, 2016 at 10:45 AM Jared Stewart wrote:

@Naba,

I filed a bug report with Spotless this morning. The Spotless devs have
been very responsive so far in my experience, hopefully this will be fixed
soon.

On Nov 4, 2016, at 10:35 AM, Nabarun Nag wrote:

@Udo, I confirmed that this is not limited to my windows 10 environment.

ran the steps on a Windows Server 2016 AMI instance and the same error
occurred in the AMI too. [source checkout time 4th Nov 10:00AM PST]

I wanted to know if there is a mandate on what the value of
core.autocrlf should
be set to on a windows machine for geode dev work. For my experiments

value

of core.autocrlf was set to true. [recommended for cross platform
development]

Regards
Naba

On Thu, Nov 3, 2016 at 10:18 PM Nabarun Nag wrote:

@Jared
I ran ./gradlew spotlessApply on the Windows 10 machine using git bash
this is what has happened.
NOTE: I started the below steps on a fresh git clone of the open side.
[Steps:
1. git clone

https://git-wip-us.apache.org/repos/asf/incubator-geode.git

open
2. cd open
3. git checkout -b develop origin/develop]

*Step 1. ./gradlew clean build -Dskip.tests=true*

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':geode-core:spotlessJavaCheck'.

Format violations were found. Run 'gradlew spotlessApply' to fix them.

geode-core\src\main\java\org\apache\geode\internal\statistics\StatArchiveReader.java
geode-core\src\test\java\org\apache\geode\cache\query\dunit\PdxLocalQueryVersionedClassDUnitTest.java
geode-core\src\test\java\org\apache\geode\internal\cache\execute\ClientServerFunctionExecutionDUnitTest.java
geode-core\src\test\java\org\apache\geode\internal\cache\functions\TestFunction.java
geode-core\src\test\java\org\apache\geode\internal\statistics\StatArchiveWithMissingResourceTypeRegressionTest.java

*Step 2: ./gradlew spotlessApply*

BUILD SUCCESSFUL

Total time: 12.728 secs

*Step 3: git status*

modified:

geode-core/src/main/java/org/apache/geode/internal/statistics/StatArchiveReader.java

modified:

geode-core/src/test/java/org/apache/geode/cache/query/dunit/PdxLocalQueryVersionedClassDUnitTest.java

modified:

geode-core/src/test/java/org/apache/geode/internal/cache/execute/ClientServerFunctionExecutionDUnitTest.java

modified:

geode-core/src/test/java/org/apache/geode/internal/cache/functions/TestFunction.java

modified:

geode-core/src/test/java/org/apache/geode/internal/statistics/StatArchiveWithMissingResourceTypeRegressionTest.java

*Step 4 : git add .*
warning: LF will be replaced by CRLF in

geode-core/src/main/java/org/apache/geode/internal/statistics/StatArchiveReader.java.

The file will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in

geode-core/src/test/java/org/apache/geode/cache/query/dunit/PdxLocalQueryVersionedClassDUnitTest.java.

The file will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in

geode-core/src/test/java/org/apache/geode/internal/cache/execute/ClientServerFunctionExecutionDUnitTest.java.

The file will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in

geode-core/src/test/java/org/apache/geode/internal/cache/functions/TestFunction.java.

The file will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in

geode-core/src/test/java/org/apache/geode/internal/statistics/StatArchiveWithMissingResourceTypeRegressionTest.java.

The file will have its original line endings in your working directory.

*Step 5: git status*
On branch develop
Your

Re: Gfsh Parsing

2016-11-04 Thread Dan Smith

+1 for simplifying the parsing and using spring shell.

-Dan

On Fri, Nov 4, 2016 at 1:42 PM, Real Wes  wrote:

> That would be a really good implementation since it would keep production
> code from relying on the formatting of the GFSH return message.  If you did
> —output=json, then the call to the GfshParser could possibly involve
> non-internal classes, which would be even nicer.
>
> > On Nov 4, 2016, at 4:31 PM, Anthony Baker  wrote:
> >
> > Wes, I think it would be interesting if we added a new option
> ‘--output=json’ to better handle the use case you described.  Then you
> could pipe the gfsh command through a json parser like jq.
> >
> > Anthony
> >
> >> On Nov 4, 2016, at 9:51 AM, Real Wes  wrote:
> >>
> >> I call the GFSH Parser from code and rely on the formatting of the
> return message to determine the response. So I’d like to see that code as
> encapsulated in one place.
> >>
> >>> On Nov 4, 2016, at 11:38 AM, Jinmei Liao  wrote:
> >>>
> >>>
> >>> We have several jira issues related to gfsh parsing (GEODE-1598,
> >>> GEODE-1912). After spending some time understanding how the parsing
> works,
> >>> I found out we have three components intertwined together all trying
> to do
> >>> parsing: Gfsh, JoptSimple and Spring Shell. I started an experiment by
> >>> getting rid of Gfsh and JoptSimple parsing and only using Spring
> Shell. The
> >>> outcome is I am able to maintain the current parsing and tabbing
> completion
> >>> capabilities (and fix a few bugs) by removing 40+ files. The only
> >>> difference I see so far lies in the help and hint messages. It seems
> the
> >>> main reason we are using these home backed Gfsh parsing is to provide
> more
> >>> readable help messages. Below are the differences:
> >>>
> >>> Using Spring Shell's provided help:
> >>>
> >>> Using Gfsh Parsing with JoptSimple:
> >>>
> >>>
> >>> I do like the outcome of the latter, but added complexity of the code
> is
> >>> too expensive to bear. So I am asking the community how important it
> is to
> >>> maintain the current style of help? Can we do with the cheaper way by
> just
> >>> using whatever provided by the libraries?
> >>>
> >>> Cheers
> >>>
> >>> Jinmei
> >>>
> >>
> >
>
>

Re: more spotless problems on Windows

2016-11-04 Thread Nabarun Nag

@Jared, sure I will verify the branch when I'm at my home windows
workstation. (Creating a AMI instance consumes a lot of time).

I will be let you know of the results asap.

Regards
Naba

On Fri, Nov 4, 2016 at 1:42 PM Jared Stewart  wrote:

> @Naba
>
> I pushed the proposed changes to a branch here:
> https://github.com/jaredjstewart/incubator-geode/tree/windowsLF <
> https://github.com/jaredjstewart/incubator-geode/tree/windowsLF>
>
> Can you see if you still have the same problem when you check out this
> branch?
>
> > On Nov 4, 2016, at 12:07 PM, Bruce Schuchardt 
> wrote:
> >
> > Udo and I tried that & it didn't work.  Maybe you'll have better luck.
> >
> > Le 11/4/2016 à 11:59 AM, Jared Stewart a écrit :
> >> From the spotless devs:
> >>
> >> Git is not a pure content store, it mucks with line endings. Regardless
> of what you check-in, it will store your files with unix line endings in
> the repo.
> >>
> >> Then, when you checkout, it will modify the line endings to suit your
> platform. Unless you add a .gitattributes file to tell git "forget the
> platform, do what this file says".
> >>
> >> Remove lineEndings 'UNIX' in your build.gradle [Jared - we should put
> ‘GIT_ATTRIBUTES’ in its place], and add a .gitattributes file in your root
> directory with the content * text eol=lf and your problem will be fixed.
> >>
> >>
> >>
> >>> On Nov 4, 2016, at 10:48 AM, Nabarun Nag  wrote:
> >>>
> >>> Thank you Jared. I wanted to confirm that this was not an isolated
> incident
> >>> specific to my machine.
> >>>
> >>> Regards
> >>> Naba
> >>>
> >>> On Fri, Nov 4, 2016 at 10:45 AM Jared Stewart 
> wrote:
> >>>
>  @Naba,
> 
>  I filed a bug report with Spotless this morning.  The Spotless devs
> have
>  been very responsive so far in my experience, hopefully this will be
> fixed
>  soon.
> 
> > On Nov 4, 2016, at 10:35 AM, Nabarun Nag  wrote:
> >
> > @Udo, I confirmed that this is not limited to my windows 10
> environment.
>  I
> > ran  the steps on a Windows Server 2016 AMI instance and the same
> error
> > occurred in the AMI too. [source checkout time 4th Nov 10:00AM PST]
> >
> > I wanted to know if there is a mandate on what the value of
> > core.autocrlf should
> > be set to on a windows machine for geode dev work. For my experiments
>  value
> > of core.autocrlf was set to true. [recommended for cross platform
> > development]
> >
> > Regards
> > Naba
> >
> >
> > On Thu, Nov 3, 2016 at 10:18 PM Nabarun Nag  wrote:
> >
> >> @Jared
> >> I ran ./gradlew spotlessApply on the Windows 10 machine using git
> bash
> >> this is what has happened.
> >> NOTE: I started the below steps on a fresh git clone of the open
> side.
> >> [Steps:
> >> 1.  git clone
>  https://git-wip-us.apache.org/repos/asf/incubator-geode.git
> >> open
> >> 2. cd open
> >> 3. git checkout -b develop origin/develop]
> >>
> >> *Step 1. ./gradlew clean build -Dskip.tests=true*
> >>
> >> FAILURE: Build failed with an exception.
> >>
> >> * What went wrong:
> >> Execution failed for task ':geode-core:spotlessJavaCheck'.
> >>> Format violations were found. Run 'gradlew spotlessApply' to fix
> them.
> >>
> 
> geode-core\src\main\java\org\apache\geode\internal\statistics\StatArchiveReader.java
> >>
> 
> geode-core\src\test\java\org\apache\geode\cache\query\dunit\PdxLocalQueryVersionedClassDUnitTest.java
> >>
> 
> geode-core\src\test\java\org\apache\geode\internal\cache\execute\ClientServerFunctionExecutionDUnitTest.java
> >>
> 
> geode-core\src\test\java\org\apache\geode\internal\cache\functions\TestFunction.java
> >>
> 
> geode-core\src\test\java\org\apache\geode\internal\statistics\StatArchiveWithMissingResourceTypeRegressionTest.java
> >>
> >> *Step 2: ./gradlew spotlessApply*
> >>
> >> BUILD SUCCESSFUL
> >>
> >> Total time: 12.728 secs
> >>
> >>
> >> *Step 3: git status*
> >>
> >> modified:
> >>
> 
> geode-core/src/main/java/org/apache/geode/internal/statistics/StatArchiveReader.java
> >>   modified:
> >>
> 
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/PdxLocalQueryVersionedClassDUnitTest.java
> >>   modified:
> >>
> 
> geode-core/src/test/java/org/apache/geode/internal/cache/execute/ClientServerFunctionExecutionDUnitTest.java
> >>   modified:
> >>
> 
> geode-core/src/test/java/org/apache/geode/internal/cache/functions/TestFunction.java
> >>   modified:
> >>
> 
> geode-core/src/test/java/org/apache/geode/internal/statistics/StatArchiveWithMissingResourceTypeRegressionTest.java
> >>
> >> *Step 4 : git add .*
> >> warning: LF will be replaced by CRLF in
> >>
> 
>

[GitHub] incubator-geode pull request #279: GEODE-1821: Adjust timing to wait for asy...

2016-11-04 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-geode/pull/279


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] incubator-geode issue #279: GEODE-1821: Adjust timing to wait for async thre...

2016-11-04 Thread dschneider-pivotal

Github user dschneider-pivotal commented on the issue:

https://github.com/apache/incubator-geode/pull/279
  
the travis failure was due to files being checked in that broke the code 
formatting checker.
This PR looks good. I will pull it in


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Gfsh Parsing

2016-11-04 Thread Real Wes

That would be a really good implementation since it would keep production code 
from relying on the formatting of the GFSH return message.  If you did 
—output=json, then the call to the GfshParser could possibly involve 
non-internal classes, which would be even nicer.

> On Nov 4, 2016, at 4:31 PM, Anthony Baker  wrote:
> 
> Wes, I think it would be interesting if we added a new option ‘--output=json’ 
> to better handle the use case you described.  Then you could pipe the gfsh 
> command through a json parser like jq.
> 
> Anthony
> 
>> On Nov 4, 2016, at 9:51 AM, Real Wes  wrote:
>> 
>> I call the GFSH Parser from code and rely on the formatting of the return 
>> message to determine the response. So I’d like to see that code as 
>> encapsulated in one place.
>> 
>>> On Nov 4, 2016, at 11:38 AM, Jinmei Liao  wrote:
>>> 
>>> 
>>> We have several jira issues related to gfsh parsing (GEODE-1598,
>>> GEODE-1912). After spending some time understanding how the parsing works,
>>> I found out we have three components intertwined together all trying to do
>>> parsing: Gfsh, JoptSimple and Spring Shell. I started an experiment by
>>> getting rid of Gfsh and JoptSimple parsing and only using Spring Shell. The
>>> outcome is I am able to maintain the current parsing and tabbing completion
>>> capabilities (and fix a few bugs) by removing 40+ files. The only
>>> difference I see so far lies in the help and hint messages. It seems the
>>> main reason we are using these home backed Gfsh parsing is to provide  more
>>> readable help messages. Below are the differences:
>>> 
>>> Using Spring Shell's provided help:
>>> 
>>> Using Gfsh Parsing with JoptSimple:
>>> 
>>> 
>>> I do like the outcome of the latter, but added complexity of the code is
>>> too expensive to bear. So I am asking the community how important it is to
>>> maintain the current style of help? Can we do with the cheaper way by just
>>> using whatever provided by the libraries?
>>> 
>>> Cheers
>>> 
>>> Jinmei
>>> 
>> 
>

Re: more spotless problems on Windows

2016-11-04 Thread Jared Stewart

@Naba

I pushed the proposed changes to a branch here: 
https://github.com/jaredjstewart/incubator-geode/tree/windowsLF 


Can you see if you still have the same problem when you check out this branch?

> On Nov 4, 2016, at 12:07 PM, Bruce Schuchardt  wrote:
> 
> Udo and I tried that & it didn't work.  Maybe you'll have better luck.
> 
> Le 11/4/2016 à 11:59 AM, Jared Stewart a écrit :
>> From the spotless devs:
>> 
>> Git is not a pure content store, it mucks with line endings. Regardless of 
>> what you check-in, it will store your files with unix line endings in the 
>> repo.
>> 
>> Then, when you checkout, it will modify the line endings to suit your 
>> platform. Unless you add a .gitattributes file to tell git "forget the 
>> platform, do what this file says".
>> 
>> Remove lineEndings 'UNIX' in your build.gradle [Jared - we should put 
>> ‘GIT_ATTRIBUTES’ in its place], and add a .gitattributes file in your root 
>> directory with the content * text eol=lf and your problem will be fixed.
>> 
>> 
>> 
>>> On Nov 4, 2016, at 10:48 AM, Nabarun Nag  wrote:
>>> 
>>> Thank you Jared. I wanted to confirm that this was not an isolated incident
>>> specific to my machine.
>>> 
>>> Regards
>>> Naba
>>> 
>>> On Fri, Nov 4, 2016 at 10:45 AM Jared Stewart  wrote:
>>> 
 @Naba,
 
 I filed a bug report with Spotless this morning.  The Spotless devs have
 been very responsive so far in my experience, hopefully this will be fixed
 soon.
 
> On Nov 4, 2016, at 10:35 AM, Nabarun Nag  wrote:
> 
> @Udo, I confirmed that this is not limited to my windows 10 environment.
 I
> ran  the steps on a Windows Server 2016 AMI instance and the same error
> occurred in the AMI too. [source checkout time 4th Nov 10:00AM PST]
> 
> I wanted to know if there is a mandate on what the value of
> core.autocrlf should
> be set to on a windows machine for geode dev work. For my experiments
 value
> of core.autocrlf was set to true. [recommended for cross platform
> development]
> 
> Regards
> Naba
> 
> 
> On Thu, Nov 3, 2016 at 10:18 PM Nabarun Nag  wrote:
> 
>> @Jared
>> I ran ./gradlew spotlessApply on the Windows 10 machine using git bash
>> this is what has happened.
>> NOTE: I started the below steps on a fresh git clone of the open side.
>> [Steps:
>> 1.  git clone
 https://git-wip-us.apache.org/repos/asf/incubator-geode.git
>> open
>> 2. cd open
>> 3. git checkout -b develop origin/develop]
>> 
>> *Step 1. ./gradlew clean build -Dskip.tests=true*
>> 
>> FAILURE: Build failed with an exception.
>> 
>> * What went wrong:
>> Execution failed for task ':geode-core:spotlessJavaCheck'.
>>> Format violations were found. Run 'gradlew spotlessApply' to fix them.
>> 
 geode-core\src\main\java\org\apache\geode\internal\statistics\StatArchiveReader.java
>> 
 geode-core\src\test\java\org\apache\geode\cache\query\dunit\PdxLocalQueryVersionedClassDUnitTest.java
>> 
 geode-core\src\test\java\org\apache\geode\internal\cache\execute\ClientServerFunctionExecutionDUnitTest.java
>> 
 geode-core\src\test\java\org\apache\geode\internal\cache\functions\TestFunction.java
>> 
 geode-core\src\test\java\org\apache\geode\internal\statistics\StatArchiveWithMissingResourceTypeRegressionTest.java
>> 
>> *Step 2: ./gradlew spotlessApply*
>> 
>> BUILD SUCCESSFUL
>> 
>> Total time: 12.728 secs
>> 
>> 
>> *Step 3: git status*
>> 
>> modified:
>> 
 geode-core/src/main/java/org/apache/geode/internal/statistics/StatArchiveReader.java
>>   modified:
>> 
 geode-core/src/test/java/org/apache/geode/cache/query/dunit/PdxLocalQueryVersionedClassDUnitTest.java
>>   modified:
>> 
 geode-core/src/test/java/org/apache/geode/internal/cache/execute/ClientServerFunctionExecutionDUnitTest.java
>>   modified:
>> 
 geode-core/src/test/java/org/apache/geode/internal/cache/functions/TestFunction.java
>>   modified:
>> 
 geode-core/src/test/java/org/apache/geode/internal/statistics/StatArchiveWithMissingResourceTypeRegressionTest.java
>> 
>> *Step 4 : git add .*
>> warning: LF will be replaced by CRLF in
>> 
 geode-core/src/main/java/org/apache/geode/internal/statistics/StatArchiveReader.java.
>> The file will have its original line endings in your working directory.
>> warning: LF will be replaced by CRLF in
>> 
 geode-core/src/test/java/org/apache/geode/cache/query/dunit/PdxLocalQueryVersionedClassDUnitTest.java.
>> The file will have its original line endings in your working directory.
>> warning: LF will be replaced by CRLF in
>>

[GitHub] incubator-geode issue #276: GEODE-1993: postprocess region/key

2016-11-04 Thread kjduling

Github user kjduling commented on the issue:

https://github.com/apache/incubator-geode/pull/276
  
precheckin running


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Gfsh Parsing

2016-11-04 Thread Anthony Baker

Wes, I think it would be interesting if we added a new option ‘--output=json’ 
to better handle the use case you described.  Then you could pipe the gfsh 
command through a json parser like jq.

Anthony

> On Nov 4, 2016, at 9:51 AM, Real Wes  wrote:
> 
> I call the GFSH Parser from code and rely on the formatting of the return 
> message to determine the response. So I’d like to see that code as 
> encapsulated in one place.
> 
>> On Nov 4, 2016, at 11:38 AM, Jinmei Liao  wrote:
>> 
>> 
>> We have several jira issues related to gfsh parsing (GEODE-1598,
>> GEODE-1912). After spending some time understanding how the parsing works,
>> I found out we have three components intertwined together all trying to do
>> parsing: Gfsh, JoptSimple and Spring Shell. I started an experiment by
>> getting rid of Gfsh and JoptSimple parsing and only using Spring Shell. The
>> outcome is I am able to maintain the current parsing and tabbing completion
>> capabilities (and fix a few bugs) by removing 40+ files. The only
>> difference I see so far lies in the help and hint messages. It seems the
>> main reason we are using these home backed Gfsh parsing is to provide  more
>> readable help messages. Below are the differences:
>> 
>> Using Spring Shell's provided help:
>> 
>> Using Gfsh Parsing with JoptSimple:
>> 
>> 
>> I do like the outcome of the latter, but added complexity of the code is
>> too expensive to bear. So I am asking the community how important it is to
>> maintain the current style of help? Can we do with the cheaper way by just
>> using whatever provided by the libraries?
>> 
>> Cheers
>> 
>> Jinmei
>> 
>

Re: Gfsh Parsing

2016-11-04 Thread Kevin Duling

+1

On Fri, Nov 4, 2016 at 11:14 AM, Jens Deppe  wrote:

> One of the 'features' of the current output is for the text to be able to
> indicate whether the command is currently available or not. Personally I
> don't think there's much value to that. If necessary, more information
> could always be added to the help text.
>
> Definitely +1 for removing code complexity.
>
> --Jens
>
> On Fri, Nov 4, 2016 at 11:06 AM, Jared Stewart 
> wrote:
>
> > Huge +1 to the idea of simplifying Gfsh parsing.  I find the green help
> > text from Spring Shell too be less readable then the black text from
> > JoptSimple, but I assume we can configure that to our choosing.
> >
> > > On Nov 4, 2016, at 10:05 AM, Jinmei Liao  wrote:
> > >
> > > This is a good idea. I'll reach out to find it out. Thanks!
> > >
> > > On Fri, Nov 4, 2016 at 9:48 AM, Michael Stolz 
> wrote:
> > >
> > >> Can we suggest improvements to the Spring help capabilities? The
> Spring
> > >> community tends to be very responsive to good suggestions.
> > >>
> > >> --
> > >> Mike Stolz
> > >> Principal Engineer - Gemfire Product Manager
> > >> Mobile: 631-835-4771
> > >> On Nov 4, 2016 8:27 AM, "Jinmei Liao"  wrote:
> > >>
> > >>> We have several jira issues related to gfsh parsing (GEODE-1598,
> > >>> GEODE-1912). After spending some time understanding how the parsing
> > >> works,
> > >>> I found out we have three components intertwined together all trying
> to
> > >> do
> > >>> parsing: Gfsh, JoptSimple and Spring Shell. I started an experiment
> by
> > >>> getting rid of Gfsh and JoptSimple parsing and only using Spring
> Shell.
> > >> The
> > >>> outcome is I am able to maintain the current parsing and tabbing
> > >> completion
> > >>> capabilities (and fix a few bugs) by removing 40+ files. The only
> > >>> difference I see so far lies in the help and hint messages. It seems
> > the
> > >>> main reason we are using these home backed Gfsh parsing is to provide
> > >> more
> > >>> readable help messages. Below are the differences:
> > >>>
> > >>> Using Spring Shell's provided help:
> > >>>
> > >>> Using Gfsh Parsing with JoptSimple:
> > >>>
> > >>>
> > >>> 
> > >>> I do like the outcome of the latter, but added complexity of the
> code
> > is
> > >>> too expensive to bear. So I am asking the community how important it
> is
> > >> to
> > >>> maintain the current style of help? Can we do with the cheaper way by
> > >> just
> > >>> using whatever provided by the libraries?
> > >>>
> > >>> --
> > >>> Cheers
> > >>>
> > >>> Jinmei
> > >>>
> > >>
> > >
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> >
> >
>

Re: more spotless problems on Windows

2016-11-04 Thread Jared Stewart

Correction:
“ * text eol=lf”
> On Nov 4, 2016, at 12:09 PM, Jared Stewart  wrote:
> 
> “ *test eol=lf”

Re: more spotless problems on Windows

2016-11-04 Thread Jared Stewart

@Bruce

To be clear, are you saying you did both of the following?

1). Create a .gitattributes file with “ *test eol=lf” at the top level of Geode
2). Change ‘UNIX’ in build.gradle to ‘GIT_ATTRIBUTES'

> On Nov 4, 2016, at 12:07 PM, Bruce Schuchardt  wrote:
> 
> Udo and I tried that & it didn't work.  Maybe you'll have better luck.
> 
> Le 11/4/2016 à 11:59 AM, Jared Stewart a écrit :
>> From the spotless devs:
>> 
>> Git is not a pure content store, it mucks with line endings. Regardless of 
>> what you check-in, it will store your files with unix line endings in the 
>> repo.
>> 
>> Then, when you checkout, it will modify the line endings to suit your 
>> platform. Unless you add a .gitattributes file to tell git "forget the 
>> platform, do what this file says".
>> 
>> Remove lineEndings 'UNIX' in your build.gradle [Jared - we should put 
>> ‘GIT_ATTRIBUTES’ in its place], and add a .gitattributes file in your root 
>> directory with the content * text eol=lf and your problem will be fixed.
>> 
>> 
>> 
>>> On Nov 4, 2016, at 10:48 AM, Nabarun Nag  wrote:
>>> 
>>> Thank you Jared. I wanted to confirm that this was not an isolated incident
>>> specific to my machine.
>>> 
>>> Regards
>>> Naba
>>> 
>>> On Fri, Nov 4, 2016 at 10:45 AM Jared Stewart  wrote:
>>> 
 @Naba,
 
 I filed a bug report with Spotless this morning.  The Spotless devs have
 been very responsive so far in my experience, hopefully this will be fixed
 soon.
 
> On Nov 4, 2016, at 10:35 AM, Nabarun Nag  wrote:
> 
> @Udo, I confirmed that this is not limited to my windows 10 environment.
 I
> ran  the steps on a Windows Server 2016 AMI instance and the same error
> occurred in the AMI too. [source checkout time 4th Nov 10:00AM PST]
> 
> I wanted to know if there is a mandate on what the value of
> core.autocrlf should
> be set to on a windows machine for geode dev work. For my experiments
 value
> of core.autocrlf was set to true. [recommended for cross platform
> development]
> 
> Regards
> Naba
> 
> 
> On Thu, Nov 3, 2016 at 10:18 PM Nabarun Nag  wrote:
> 
>> @Jared
>> I ran ./gradlew spotlessApply on the Windows 10 machine using git bash
>> this is what has happened.
>> NOTE: I started the below steps on a fresh git clone of the open side.
>> [Steps:
>> 1.  git clone
 https://git-wip-us.apache.org/repos/asf/incubator-geode.git
>> open
>> 2. cd open
>> 3. git checkout -b develop origin/develop]
>> 
>> *Step 1. ./gradlew clean build -Dskip.tests=true*
>> 
>> FAILURE: Build failed with an exception.
>> 
>> * What went wrong:
>> Execution failed for task ':geode-core:spotlessJavaCheck'.
>>> Format violations were found. Run 'gradlew spotlessApply' to fix them.
>> 
 geode-core\src\main\java\org\apache\geode\internal\statistics\StatArchiveReader.java
>> 
 geode-core\src\test\java\org\apache\geode\cache\query\dunit\PdxLocalQueryVersionedClassDUnitTest.java
>> 
 geode-core\src\test\java\org\apache\geode\internal\cache\execute\ClientServerFunctionExecutionDUnitTest.java
>> 
 geode-core\src\test\java\org\apache\geode\internal\cache\functions\TestFunction.java
>> 
 geode-core\src\test\java\org\apache\geode\internal\statistics\StatArchiveWithMissingResourceTypeRegressionTest.java
>> 
>> *Step 2: ./gradlew spotlessApply*
>> 
>> BUILD SUCCESSFUL
>> 
>> Total time: 12.728 secs
>> 
>> 
>> *Step 3: git status*
>> 
>> modified:
>> 
 geode-core/src/main/java/org/apache/geode/internal/statistics/StatArchiveReader.java
>>   modified:
>> 
 geode-core/src/test/java/org/apache/geode/cache/query/dunit/PdxLocalQueryVersionedClassDUnitTest.java
>>   modified:
>> 
 geode-core/src/test/java/org/apache/geode/internal/cache/execute/ClientServerFunctionExecutionDUnitTest.java
>>   modified:
>> 
 geode-core/src/test/java/org/apache/geode/internal/cache/functions/TestFunction.java
>>   modified:
>> 
 geode-core/src/test/java/org/apache/geode/internal/statistics/StatArchiveWithMissingResourceTypeRegressionTest.java
>> 
>> *Step 4 : git add .*
>> warning: LF will be replaced by CRLF in
>> 
 geode-core/src/main/java/org/apache/geode/internal/statistics/StatArchiveReader.java.
>> The file will have its original line endings in your working directory.
>> warning: LF will be replaced by CRLF in
>> 
 geode-core/src/test/java/org/apache/geode/cache/query/dunit/PdxLocalQueryVersionedClassDUnitTest.java.
>> The file will have its original line endings in your working directory.
>> warning: LF will be replaced by CRLF in
>>

Re: more spotless problems on Windows

2016-11-04 Thread Bruce Schuchardt

Udo and I tried that & it didn't work. Maybe you'll have better luck.

Le 11/4/2016 à 11:59 AM, Jared Stewart a écrit :

From the spotless devs:

Git is not a pure content store, it mucks with line endings. Regardless of what
you check-in, it will store your files with unix line endings in the repo.

Then, when you checkout, it will modify the line endings to suit your platform. Unless
you add a .gitattributes file to tell git "forget the platform, do what this file
says".

On Nov 4, 2016, at 10:48 AM, Nabarun Nag wrote:

Thank you Jared. I wanted to confirm that this was not an isolated incident
specific to my machine.

Regards
Naba

On Fri, Nov 4, 2016 at 10:45 AM Jared Stewart wrote:

@Naba,

I filed a bug report with Spotless this morning. The Spotless devs have
been very responsive so far in my experience, hopefully this will be fixed
soon.

On Nov 4, 2016, at 10:35 AM, Nabarun Nag wrote:

@Udo, I confirmed that this is not limited to my windows 10 environment.

ran the steps on a Windows Server 2016 AMI instance and the same error
occurred in the AMI too. [source checkout time 4th Nov 10:00AM PST]

I wanted to know if there is a mandate on what the value of
core.autocrlf should
be set to on a windows machine for geode dev work. For my experiments

value

of core.autocrlf was set to true. [recommended for cross platform
development]

Regards
Naba

On Thu, Nov 3, 2016 at 10:18 PM Nabarun Nag wrote:

@Jared
I ran ./gradlew spotlessApply on the Windows 10 machine using git bash
this is what has happened.
NOTE: I started the below steps on a fresh git clone of the open side.
[Steps:
1. git clone

https://git-wip-us.apache.org/repos/asf/incubator-geode.git

open
2. cd open
3. git checkout -b develop origin/develop]

*Step 1. ./gradlew clean build -Dskip.tests=true*

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':geode-core:spotlessJavaCheck'.

Format violations were found. Run 'gradlew spotlessApply' to fix them.

geode-core\src\main\java\org\apache\geode\internal\statistics\StatArchiveReader.java

geode-core\src\test\java\org\apache\geode\cache\query\dunit\PdxLocalQueryVersionedClassDUnitTest.java

geode-core\src\test\java\org\apache\geode\internal\cache\execute\ClientServerFunctionExecutionDUnitTest.java

geode-core\src\test\java\org\apache\geode\internal\cache\functions\TestFunction.java

geode-core\src\test\java\org\apache\geode\internal\statistics\StatArchiveWithMissingResourceTypeRegressionTest.java