[IO-414] Don't write a BOM on every (or any) line

[elharo]

Something very weird happened with the previous iteration of this PR. This PR should work.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 84.88%. Comparing base (633d663) to head (5f69f51).
⚠️ Report is 1610 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##             master     #493   +/-   ##
=========================================
  Coverage     84.88%   84.88%           
- Complexity     3381     3382    +1     
=========================================
  Files           228      228           
  Lines          8116     8117    +1     
  Branches        960      961    +1     
=========================================
+ Hits           6889     6890    +1     
  Misses          964      964           
  Partials        263      263           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[garydgregory]

Hi @elharo
You can run mvn from a command shell to catch these build errors. mvn runs our default goal which includes all the checks.

[elharo]

mvn test doesn't catch checkstyle errors. I have to look for those specifically.

On the previous iteration, the CI passed on my PR. The code was somehow modified after I submitted it.

[garydgregory]

mvn test doesn't catch checkstyle errors. I have to look for those specifically.

On the previous iteration, the CI passed on my PR. The code was somehow modified after I submitted it.

No you don't, as noted above, run mvn, by itself, this causes the default Maven goal to run, which includes all of the checks.

[garydgregory]

Side note: In general, don't edit changes.xml in PRs, this usually causes conflicts if another PR also edits that file or if, invariably, that file has been edited in the course of plain old development.

As an alternative, we could use Log4j's change log mechanism which avoids any and all conflicts.