royteeuwen opened a new pull request, #54:
URL: https://github.com/apache/sling-org-apache-sling-committer-cli/pull/54

   The log attached to the issue shows nine failures with three distinct causes.
   
   ## 1. No `.gitattributes` (5 failures)
   
   Git for Windows defaults to `core.autocrlf=true`, so fixtures are rewritten 
on checkout. That breaks `HashValidatorTest.testValidHashes` and 
`PGPSignatureValidatorTest.verifyPGPSignatures`, which hash and PGP-verify a 
`.pom` byte-for-byte, and `TallyVotesCommandTest.testAuto`/`testDryRun` plus 
`PrepareVoteEmailCommandTest`, which compare generated mail against Java text 
blocks — the compiler normalises those to LF, so a CRLF template can never 
match.
   
   Reproduced by converting the resources to CRLF locally: exactly those tests 
fail, plus `testDryRunNonPmc` which did not exist in 2023. Fixed with `* -text`.
   
   ## 2. `Files.write(Path, Iterable)` uses the platform separator (3 failures)
   
   `JBakeContentUpdater` lines 68/213/255. On Windows this rewrites every line 
of the LF-only site sources, so the diff covers the whole file — the log shows 
`item 0: was " \r"`, and under simulation the diff starts at the licence header.
   
   **This is a production bug, not just a test one:** on Windows 
`update-local-site` would push a whole-file rewrite of `releases.md`, `news.md` 
and `downloads.tpl` to the website instead of the intended change. Fixed with 
an explicit-LF helper.
   
   ## 3. Unclosed `OutputStream` (1 error)
   
   `RepositoryService.downloadFileFromRepository`:
   
   ```java
   IOUtils.copyLarge(content, Files.newOutputStream(filePath));
   ```
   
   The stream is never closed, so every downloaded artifact leaves an open 
write handle. On Windows `Files.delete(file)` only marks it delete-pending, the 
directory entry survives, and `RemoveDirectory` on the parent then fails with 
`ERROR_DIR_NOT_EMPTY` — the `DirectoryNotEmptyException` at 
`RepositoryServiceTest.testDownloadRepository:150`. It is also a plain 
descriptor leak on every platform: one per artifact file, times five sidecars, 
held for the life of the process. Now wrapped in try-with-resources; the two 
leaked `Files.walk` streams in that test are closed too (hygiene, not the 
cause).
   
   ## Also
   
   Drops the `operatingSystems` pin added as a workaround in #24, so the 
Windows build runs again and this PR can confirm the fix.
   
   ## Verification
   
   `mvn verify` green normally and under `line.separator=CRLF`: 183 tests, 0 
failures, 0 errors both ways.
   
   **Caveat:** I have no Windows machine. Causes 1 and 2 are reproduced by 
simulating each mechanism; cause 3 is diagnosed by reading, since POSIX happily 
deletes files with open handles. The leak is unambiguous and explains that 
exact exception type, but the Windows CI run on this PR is what actually proves 
it was the whole story.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to