Looks like it's a feature: https://github.com/google/google-java-format/issues/62
Is it too late to down-vote our use of google-java-format? On Tue, Aug 21, 2018 at 3:43 PM, Kirk Lund <kl...@apache.org> wrote: > I suppose I was using that older format of the Apache license header and > then using spotlessApply 100% before running spotlessCheck which was > reformatting the license header. So even though I was using the older one, > I never ran into the problem until today. > > So maybe nothing changed? > > But, I still think it's ridiculous that we have spotless configured to > disallow a double-space after sentence terminator. > > On Tue, Aug 21, 2018 at 3:39 PM, Kirk Lund <kl...@apache.org> wrote: > >> I know it's not a bug in spotless. I think we now have the settings a bit >> too strict. >> >> As of 2-3 weeks ago, I was able to follow the "Setting up IntelliJ" >> process that I documented at https://github.com/gemfire/gemfire (search >> down for "Setting up IntelliJ") without spotless failing. See the format >> of the Apache license header that's pasted into that readme? It has the >> extra spaces, including 2 spaces between sentences. >> >> 2-3 weeks ago, this was working fine. Now it fails spotless, so something >> changed. Maybe the version of spotless that we're using in gradle? Or a >> gradle spotless plugin version changed? >> >> At best, it's laughable that our spotless format now complains about >> correct English syntax in comments and javadocs. At worst, it's evidence >> that our use of spotless is... "a bit too strict" which in my opinion >> should be fixed. >> >> Can you please look into what changed? I haven't had much luck finding it >> yet but I assure you that something did change. >> >> On Tue, Aug 21, 2018 at 2:26 PM, Patrick Rhomberg <prhomb...@pivotal.io> >> wrote: >> >>> The only addition with respect to spotless on the 10th was to add the >>> `devBuild` target (which runs `spotlessApply`) and to require that >>> `spotlessApply` would run before `compileJava`, if both were to run in a >>> given build command. >>> >>> Looking at the PR against which these failed, it looks like it might be >>> some disagreement between your IDE's desired format and spotless's. >>> Notably, the new test file header is thinner and has more space >>> padding. I >>> hadn't thought spotless cared about comment blocks, but looking now, it >>> does look like we're consistent everywhere else (within the Java code >>> that >>> spotless targets) on how that header is formatted. >>> >>> So, you know... It's a feature, not a bug? And we should investigate the >>> discrepancies between the format files in <geode>/etc, that is, the >>> Eclipse >>> file spotless uses and the IntelliJ file that is meant to emulate it. >>> >>> On Tue, Aug 21, 2018 at 9:48 AM, Kirk Lund <kl...@apache.org> wrote: >>> >>> > This appears to be caused by changes made to the build around August >>> 10? >>> > >>> > On Tue, Aug 21, 2018 at 9:38 AM, Kirk Lund <kl...@apache.org> wrote: >>> > >>> > > Why is spotless now complaining about correct English? By correct >>> > English, >>> > > I mean having 2 spaces between sentences in javadoc or comments (in >>> this >>> > > case it's the Apache license header): >>> > > >>> > > -·*·the·License.··You·may·obtain·a·copy·of·the·License·at >>> > > +·*·the·License.·You·may·obtain·a·copy·of·the·License·at >>> > > >>> > > Execution failed for task ':geode-core:spotlessJava'. >>> > > <https://concourse.apachegeode-ci.info/builds/19648#L5b60a2a0:1903> >>> > > > The following files had format violations: >>> > > <https://concourse.apachegeode-ci.info/builds/19648#L5b60a2a0:1904> >>> > > geode-core/src/main/java/org/apache/geode/internal/cache/ >>> > RegionNameValidation.java >>> > > <https://concourse.apachegeode-ci.info/builds/19648#L5b60a2a0:1905> >>> > > @@ -1,12 +1,12 @@ >>> > > <https://concourse.apachegeode-ci.info/builds/19648#L5b60a2a0:1906> >>> > > /* >>> > > <https://concourse.apachegeode-ci.info/builds/19648#L5b60a2a0:1907> >>> > > ·*·Licensed·to·the·Apache·Software·Foundation·(ASF)· >>> > under·one·or·more >>> > > <https://concourse.apachegeode-ci.info/builds/19648#L5b60a2a0:1908> >>> > > -·*·contributor·license·agreements.··See·the·NOTICE· >>> > file·distributed·with >>> > > <https://concourse.apachegeode-ci.info/builds/19648#L5b60a2a0:1909> >>> > > +·*·contributor·license·agreements.·See·the·NOTICE· >>> > file·distributed·with >>> > > <https://concourse.apachegeode-ci.info/builds/19648#L5b60a2a0:1910> >>> > > ·*·this·work·for·additional·information·regarding· >>> > copyright·ownership. >>> > > <https://concourse.apachegeode-ci.info/builds/19648#L5b60a2a0:1911> >>> > > ·*·The·ASF·licenses·this·file·to·You·under·the·Apache· >>> > License,·Version·2.0 >>> > > <https://concourse.apachegeode-ci.info/builds/19648#L5b60a2a0:1912> >>> > > ·*·(the·"License");·you·may·not·use·this·file·except·in· >>> > compliance·with >>> > > <https://concourse.apachegeode-ci.info/builds/19648#L5b60a2a0:1913> >>> > > -·*·the·License.··You·may·obtain·a·copy·of·the·License·at >>> > > <https://concourse.apachegeode-ci.info/builds/19648#L5b60a2a0:1914> >>> > > +·*·the·License.·You·may·obtain·a·copy·of·the·License·at >>> > > <https://concourse.apachegeode-ci.info/builds/19648#L5b60a2a0:1915> >>> > > ·* >>> > > <https://concourse.apachegeode-ci.info/builds/19648#L5b60a2a0:1916> >>> > > -·*······http://www.apache.org/licenses/LICENSE-2.0 >>> > > <https://concourse.apachegeode-ci.info/builds/19648#L5b60a2a0:1917> >>> > > +·*·http://www.apache.org/licenses/LICENSE-2.0 >>> > > <https://concourse.apachegeode-ci.info/builds/19648#L5b60a2a0:1918> >>> > > ·* >>> > > <https://concourse.apachegeode-ci.info/builds/19648#L5b60a2a0:1919> >>> > > ·*·Unless·required·by·applicable·law·or·agreed·to· >>> > in·writing,·software >>> > > <https://concourse.apachegeode-ci.info/builds/19648#L5b60a2a0:1920> >>> > > ·*·distributed·under·the·License·is·distributed·on·an·" >>> > AS·IS"·BASIS, >>> > > >>> > > >>> > > >>> > >>> >> >> >
