revert "Set UNIX-style linebreaks"

[LorenzoBettini]

Take the EOL settings from the OS, so that Xtend generated Java files are not "dirty" when regenerated in a Windows system.

Closes #2778

[LorenzoBettini]

By the way, this change is of course harmless to Linux and macOS

[cdietrich]

@szarnekow wdyt?

[LorenzoBettini]

In windows, this allows me to avoid tons of dirty files.

[cdietrich]

unfortunately this is in the codebase "forever"
i also cannot test if there is any bad side effect.
what does this preference do?

what happens if someone opens a pr on windows?

[LorenzoBettini]

@cdietrich I'll try to summarize the reasons for this PR and the problems of #2778

unfortunately this is in the codebase "forever" i also cannot test if there is any bad side effect. what does this preference do?

This preference, which I remove in this PR, tells Eclipse that every file generated from Eclipse must have Unix EOL, while the default is to use the System EOL.

Using such a setting, together with the recommended setting in Windows autocrlf=true, breaks the Windows experience: as soon as you run a clean build from Eclipse in Windows, all Java files generated by Xtend, in the projects with this setting, will be "dirty" since they will have Unix EOL. About 500 files will be dirty. Note that these settings are not even in all projects with Xtend files since they were added so many years ago.

Remember that autocrlf=true means that in Git files are with Unix EOL, and when checkout they get Windows EOL. When committed they will get Unix EOL.

As @szarnekow suggested, those settings, dated back to 2012, were probably needed because at that time, we committed trace files as well (we were using Buckminster) and that setting allowed for consistent trace files. Nowadays, trace files are generated during the build, where, by the way, those settings are ignored (they are relevant only in Eclipse), so they are not needed anymore for that matter.

what happens if someone opens a pr on windows?

Without this PR, files might end up in the Git repository with wrong EOLs and/or with too many unrelated changes. Not to mention that Windows contributors will have hard time understanding what to commit, and, as it happened recently, a few files will not be committed.

#2977 already fixed many files that ended up with the wrong EOL. The presence of these settings is probably the culprit behind the files with wrong EOLs that ended up in the Git repository in the past.

Please let me know if you need further information.

[cdietrich]

So I assume this won’t have side effects

[LorenzoBettini]

So I assume this won’t have side effects

I haven't found any; I found lots of side effects without this PR ;)

@szarnekow are you OK with this PR?

[szarnekow]

Yes