Fixes for #349

[pypmannetjies]

Changed the excludes to use the string as a regular expression except in
the case where a "path" option is provided. Where a path is provided, it
should work as before. Removed the appended class name because the
simpler provided path will still match paths checked against it.

[Gama11]

Compilation on Travis is failing:

https://travis-ci.org/HaxeCheckstyle/haxe-checkstyle/jobs/266828167#L305-L308

[pypmannetjies]

My bad! Some last minute refactoring I didn't check.

[AlexHaxe]

• Sys.println shows lots of null lines in travis and in a local compile run. I guess it's a left over from debugging.
• excludes in checkstyle.json are broken -> see output from travis (https://travis-ci.org/HaxeCheckstyle/haxe-checkstyle/jobs/266834906#L414-L446)
• please remove trailing whitespace and add missing return type for normalisePath

[pypmannetjies]

Ok now I'm not too sure why the build is failing:

haxe: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.17' not found (required by haxe)

[AlexHaxe]

Don't worry about libc.so.6, it seems to be a problem with the development version of Haxe and / or Travis's Haxe support.
I don't think it has anything to do with your changes.

[Gama11]

That can be fixed by adding dist: trusty to the Travis config.

HaxeFlixel/flixel@9416bde

I'll do that in a separate PR.

[AlexHaxe]

Was just about to do that, but you were faster... :)

[codecov-io]

Codecov Report

Merging #350 into dev will decrease coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##              dev     #350      +/-   ##
==========================================
- Coverage   89.78%   89.78%   -0.01%     
==========================================
  Files         116      116              
  Lines        7331     7330       -1     
  Branches      293      293              
==========================================
- Hits         6582     6581       -1     
  Misses        489      489              
  Partials      260      260

Impacted Files	Coverage Δ
src/checkstyle/Checker.hx	82.66% <100%> (-0.06%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update aa81ca1...dab5a0e. Read the comment docs.

[pypmannetjies]

@AlexHaxe for now I've got it so it uses straight regex if you don't specify "path" option in inside checkstyle.json. This may break existing configurations. Would you prefer we rather add a new option e.g. "regex": "true" or something like that, or is my approach acceptable?

[AlexHaxe]

If we introduce a breaking change, then users have to change their config files. We would have to communicate it with the next release.
If there is a way to keep old configs working and make new functionality optional, then we should at least consider it.

I am not opposed to a breaking change - I personally don't use exclusions in my checkstyle.json (mainly because I use one config for many projects), so I am not personally affected.
And I do see a use case for having a regex to exclude files from checkstyle, but mostly in the phase where you start using checkstyle on a large codebase (there might be other use cases, that I am unaware of).
The number of checkstyle issues can be quite overwhelming, especially if you create a config that enables a lot of checks. But the goal of using checkstyle is to reduce the number of issues. If you have to exclude half of your codebase, then maybe just disable that particular check.

And we should make checkstyle not emit checkstyle warnings during build (either by fixing issues or by using limited exclusions).

[pypmannetjies]

I don't think many users use excludes which is probably why this is only now becoming an issue. We need to apply different rules for tests vs source code. For example, tests may need to use long functions to mock out objects, etc. We don't want a separate checkstyle.json for tests because all the other rules are still shared.

The problem with using the excludes as-is is that you can't filter on a class name at all. It seems you can only specify a different package. I suppose we could get away with just refactoring how the paths work but regex is a nice to have and is actually pretty simple vs. the other "path" options.

[AlexHaxe]

Checkstyle supports a checkstyle-exclude.json and -e command line parameter, so you can share your checkstyle rules and still have individual exlcusions.

Also the current state of exclusion handling is a work in progress implementation of #120 that became a quasi "permanent" solution. I think before #120 you could only suppress checks using inline annotations e.g. @SuppressWarnings("checkstyle:<checkname>"), which only worked in places where annotations are part of the AST.

For the sake of this pull request I would say we update checkstyle.json so our build passes without checkstyle issues.