Newlines are modified in files I did not touch

Development
, ,
Tags: #<Tag:0x00007efec2c6da78> #<Tag:0x00007efec2c6d988> #<Tag:0x00007efec2c6d870>
#1

Today I installed Eclipse (on Windows 10) according to the instructions on this page: Eclipse IDE | openHAB

I have Maven and openJDK 11 installed as well.

I forked the addon repo and then created a skeleton for a new binding, implemented a simple binding and was indeed able to bring up and test the binding according to the description.

When I wanted to commit the progress to a branch I noticed however that several files outside my project have been modified, with the only changes being the line endings:

For instance pom.xml in bundles:

image
image840×383 14.5 KB

Other files affected are CODEOWNERS and bom/openhab-addons/pom.xml

Is this a setting in Eclipse somewhere?

And speaking of Eclipse… will it keep using 20-100% CPU all the time? It just keeps building and building and invoking and building and waiting and refreshing IDE (for almost 3 hours now)

Regards,

Daniel

#2

I’d let the build complete and turn off the auto-build to prevent that. Autobuild will automatically do that anytime you save a file for the most part.

#3

This might be some setting that coverts line endings to windows line endings when the skeleton script modifies those files. But I would not know what causes this. Maybe a git setting?

What projects did you import in eclipse?

#4

I have openhab-distro and openhab-addons.

Git is Git for Windows 2.28, I’ll see if I can find something there for the newlines.

#5

The repo has a .gitattributes file which sets the automatic conversion on checkout for Windows to CRLF, this file was added fairly recent (October 20): History for .gitattributes - openhab/openhab-addons · GitHub

However, then it should apply to every file.

I did revert the bundles pom.xml file and then created another skeleton and indeed now I do have the additional ‘empty’ lines again. Thing is in fact, they are not empty but they do contain spaces (multiples of 4, roughly following the indent level of the xml)

(Wild guess: git adds \r and the script treats both \r and \n as lines and then inserts a line with indentation for each)

The CODEOWNER file seems to be something different. My first binding was not added, my second is in there.

I’ll copy my work and start from a clean repo to be able to better see what is going on.

#6

I think what is happening:

  • In the repo the files have 0x0a line endings
  • Because of the .gitattributes setting they get converted to 0x0d 0x0a on check out on windows. (Before pushing Git will convert back)
  • The scripts to update pom.xml and CODEOWNERS fail to do what they should do because of the 0x0d 0x0a line endings, no contents get added.
  • However, they do convert the line endings back to 0x0d
  • Then when running the skeleton creation scripts a second time they do work properly.

I’ll remove the .gitattributes in my fork, I expect things will work then (after a fresh pull)

No, doesn’t work since the spotless check does actually expect the CRLF linefeeds to be there. So I guess I’ll have to find the skeleton script then.