You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's relatively common on projects to standardize on Unix line endings even when doing development on Windows, mostly for the sanity of all involved. sbt-header mostly handles this in a reasonable way in every respect except for the fact that it appears to constantly try to recreate headers. The detection hard-codes System.lineSeparator() as the expected line terminator, and so what happens if you have a bunch of files with valid license headers but the "wrong" line ending is sbt-header will detect them all as needing new headers, then write a new header for each file using the overridden line endings (since we control the license contents), ultimately leaving the file unchanged. The practical effect of this is that sbt-header touches every file on every compile, leaving their contents unchanged but still re-written to disk.
This in turn requires workarounds like this to make sbt-header meaningfully usable across platforms.
If we had the ability to configure newLine, this really wouldn't be an issue. Or if there was at least a sanity check to ensure that newLine matched the line endings used in the configured license (usually \n).
The text was updated successfully, but these errors were encountered:
Yes, this is a Windows issue. :-(
It's relatively common on projects to standardize on Unix line endings even when doing development on Windows, mostly for the sanity of all involved. sbt-header mostly handles this in a reasonable way in every respect except for the fact that it appears to constantly try to recreate headers. The detection hard-codes
System.lineSeparator()
as the expected line terminator, and so what happens if you have a bunch of files with valid license headers but the "wrong" line ending is sbt-header will detect them all as needing new headers, then write a new header for each file using the overridden line endings (since we control the license contents), ultimately leaving the file unchanged. The practical effect of this is that sbt-header touches every file on every compile, leaving their contents unchanged but still re-written to disk.This in turn requires workarounds like this to make sbt-header meaningfully usable across platforms.
If we had the ability to configure
newLine
, this really wouldn't be an issue. Or if there was at least a sanity check to ensure thatnewLine
matched the line endings used in the configured license (usually\n
).The text was updated successfully, but these errors were encountered: