As you consider this to be a bug, please specify a reference that mandates well-formed XML files need to end with a line break.

i didnt say they werent well-formed XML files. i said that they are not well-formed text files.

POSIX is a widely-accepted standard. here are the relevant POSIX definitions:

3.397 Text File
A file that contains characters organized into zero or more lines. The lines do not contain NUL characters and none can exceed

bytes in length, including the <newline> character.

3.206 Line
A sequence of zero or more non-<newline> characters plus a terminating <newline> character.

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html

however, it is much more practically important to note that many standard, popular, extremely widely-deployed tools rely on this definition

. there are no tools that i ever heard of that require special lines NOT to end in the newline character.

I'm also having the same issue.

I use chef to manage my jenkins config files (jobs, plugins, etc), so whenever one of these files is edited by Unix tools such as VI, a newline is appended to the end of file, causing the file to be reloaded everytime chef is applied (since it's different from the jenkins parsed file, without newline).

I don't remember having this problem with verison 1.563, but now that upgraded to 1.590 started happening, so probably it was introduced recently.

I was wrong. The problem also happens in 1.563.

Calling this one an improvement makes more sense IMO. Jenkins, a Java application, runs on Windows as well, and text editors there don't add trailing newlines, so the applicability of POSIX on Jenkins isn't a given.

While it should be straightforward to just add a newline to the end of every XmlFile, the problem is how to introduce this. Otherwise all users will see changes to files for no real reason when they didn't modify XML configuration using a Unix tool.

"Only append if the previous file ended in a new line" maybe? That would be weird (why do some files end in newlines while others don't?), and you still get a change recorded whenever you edit a job's file for the first time.

perhaps a less weird way to describe your proposal would be to format all lines the same by default, except when the only difference is that the last line in the old file did not end in newline. this would make it so that you dont get a change recorded when you edit a jobs file for the first time, and it would still be stable and backwards-compatible.

i would like to point out, also, that editing config files without making changes is ALREADY allowed to produce a file with a difference checksum. it happens all the time, if you upgrade jenkins or any plugins. it would be unlikely for this to be the only change anyway.