Add check to prohibit Windows line endings

[gaul]

While RegexpMultiline can do this it is not discoverable by users:

<module name="RegexpMultiline">
    <property name="format" value="\r\n"/>
    <property name="message" value="Do not use Windows line endings"/>
</module>

ATTENTION: new Check discussion is moved to new issue - #18109

[romani]

We always try to make a general Checks, so check should enforce user defined LineEnd symbol.

We will consider that idea as soon as we finish moratorium period for new Checks, if you ready to implement it , please be welcome at our experimental Check project - https://github.com/sevntu-checkstyle/sevntu.checkstyle.

[pbaranchikov]

This check is completely useless, as good VCS configuration will force local working copy to have Windows-like (CRLF) EOL-style on Windows clients and Linux EOL-style (LF) on Linux clients. In this way, the correctly configured clients should have multiple errors for checkstyle.

This contstraint is to be forced inside your VCS. For Stash you may use https://github.com/pbaranchikov/stash-eol-check, for gitolite-admin you should perform some BASH-scripting and so on.

[romani]

@andrewgaul , what kind of VCS you have ? GIT manage it as pbaranchikov described.

[gaul]

@pbaranchikov I agree that correctly configured git clients can warn about line endings via various hooks, although as a project admin using GitHub there is no real way to enforce this on either the server or our contributors' clients. We enabled the previously mentioned RegexpMultiline in jclouds/jclouds#717.

[mkordas]

I don't think this rule is a good idea. Using git, you have no control which EOL style your clients use. We may end up with rule that passes on CI, but fails for people using Windows.

[isopov]

At my work we are using git without enforcing line endings and we do enforce them with checkstyle in java sources.
Test inputs have different line endings to test that file based logic works as expected with any combination.

[msteiger]

I completely agree with @andrewgaul - such a check could be very valuable imho. Inconsistent line endings can certainly cause problems, in particular for resources files (config files, csv files, etc).

Let's assume for a second that git is used. Clients can decide how files are converted using the core.autocrlf feature. Some of them might have turned it off, leading to Windows clients pushing CRLF line endings, which is not supposed to happen according to git standards. If your code assumes LF line endings, a CSV file might become unreadable 😢

@mkordas Actually, you can configure line endings very nicely using the .gitattributes file. See #1045 for example. You can also specify line endings per file type and git can also try to automatically detect and performs EOL conversion. Unfortunately, the jgit implementation that eclipse uses simply ignores the .gitattributes file 😢

To sum it up: A check that verifies that only text/code files with LF line endings are committed makes perfectly sense to me as ensures consistency of the code files and thus helps avoiding bugs that are really hard to track down.

[mkordas]

@msteiger, generally I agree with you. I had issues with newlines in my projects too. I have just couple concerns:

1. Let's assume we have developers using Windows and CI on Linux and check is configured to enforce LF - Checkstyle would fail on development machines
2. Let's assume we've added property e.g. "match system line separator" to enforce LF on Unix and CRLF on Windows - Checkstyle would fail for all developers that have autocrlf disabled
3. Let's assume we use .gitattributes file - then each entry from this file needs suppression in Checkstyle config...
4. Let's assume developer has all files as CRLF on Windows but temporarily wants to execute bash script using Cygwin, so dos2unix is required. Checkstyle would fail, even if then Git afterwards would manage that case.

I'm just not convinced to have the check that is so fragile, but maybe just good description (and warning) in documentation would be enough.

[vorburger]

+1 @andrewgaul et al IMHO this is most certainly a good idea and would be great to have built-in! Note "(?s:\r\n.*)" is better because it will only match the first wrong newline, so less spammy logs (and perhaps even faster?). See also my blurb (blog post) about this on http://blog2.vorburger.ch/2015/06/eol.html.

[romani]

There are bunch of VCS, so might be some VCS does not handle that correctly.

Somebody could make this Check if it is required, all are welcome to contribute.