ArchUnit
ArchUnit copied to clipboard
Spotless complains about line endings on Windows with core.autocrlf=false
Extracted this issue from PR #427, see also the discussion on that PR...
The ArchUnit build gradlew build
fails currently on my Windows machine:
Execution failed for task ':archunit:spotlessJavaCheck'.
> The following files had format violations:
archunit\src\jdk9main\java\com\tngtech\archunit\core\domain\Java9DomainPlugin.java
@@ -1,36 +1,36 @@
-/*\n
- * Copyright 2014-2020 TNG Technology Consulting GmbH\n
- *\n
...
+/*\r\n
+ * Copyright 2014-2020 TNG Technology Consulting GmbH\r\n
+ *\r\n
...
... (24 more lines that didn't fit)
Violations also present in 662 other files.
Run 'gradlew.bat :archunit:spotlessApply' to fix these violations.
Spotless wants to change the line endings of all files in my working copy from \n to \r\n.
My Git is configured to core.autocrlf=false
, so the line endings in my working copy are \n.
Creating a .gitattributes
file with the content
*.java text eol=lf
worked for me, but failed on GitHub's Windows runner, see https://github.com/TNG/ArchUnit/runs/1166974355
Execution failed for task ':archunit-junit4:spotlessJavaCheck'.
> The following files had format violations:
archunit-junit\junit4\src\main\java\com\tngtech\archunit\junit\AnalyzeClasses.java
@@ -1,18 +1,18 @@
-/*\r\n
- * Copyright 2014-2020 TNG Technology Consulting GmbH\r\n
- *\r\n
...
+/*\n
+ * Copyright 2014-2020 TNG Technology Consulting GmbH\n
+ *\n
...
In this case, Spotless wants to change the line endings from \r\n to \n.
Spotless has an issue for this topic which is not resolved currently: https://github.com/diffplug/spotless/issues/540
I ran into the same issue, .gitattributes
did the trick as mentioned above.
After that, the JavaClassDescriptorTest fails due to an encoding issue which can be fixed by adding these lines to build.gradle
:
compileJava.options.encoding = "UTF-8"
compileTestJava.options.encoding = "UTF-8"
The issue https://github.com/diffplug/spotless/issues/540 is fixed with Spotless 6.2.1. So this issue should be fixed by merging #782. (or a follow-up PR if dependabot is faster)