I’m +1 to the idea of using something to handle the auto-formatting of code.
HOWEVER, I want to make it clear that this will likely NOT remove checkstyle from the builds as there are things that checkstyle checks that aren’t part of this. Variable names, type names, javadoc things, etc…. Are things that checkstyle currently handles that are not solved by this. Checkstyle can also be used to enforce some other coding issues. For example: checkstyle can mark imports of java.util.logging as a problem to link this to another thread on the list. :) That said, the checkstyle rules for whitespace and paren padding and brace placement and such can all be turned off. They likely will have to be turned off. Last time I attempted to use spotless, I couldn’t get a set of checkstyle rules that would be a 100% match for what spotless generates. Dan > On Jun 27, 2018, at 3:42 PM, Ismaël Mejía <ieme...@gmail.com> wrote: > > ++1 > > - This solves the big mismatch of autoformatting using eclipse's google java > style and the google-java-format plugin that makes a common source of > unneeded diffs part of the reviews. > - The spotless plugin makes this trivial to do and uniform. > > We need to update the instructions on formatting and we need to remove > checkstyle and the Eclipse codestyle template from the repo too. So probably > worth a JIRA/PR for this too. My preference is to do it all at once because > the tool helps to do it quickly and we will have the pain only once and it > will be fixed forever. Only thing that bugs me is that we will break probably > most of the Java open Pull Requests. From a quicklook there are around 15 PRs > from non active contributors that could end up staling if not rebased, so > probably worth a message in these PRs remembering to rebase and linking the > new autoformatting docs. > -- Daniel Kulp dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog> Talend Community Coder - http://coders.talend.com <http://coders.talend.com/>
