wilx opened a new pull request, #1341:
URL: https://github.com/apache/maven-assembly-plugin/pull/1341
Fixes #1154.
## Summary
Normalize old Mac CR-only line endings to CRLF when an assembly file set uses
`<lineEnding>crlf</lineEnding>` (or its `windows`/`dos` aliases).
`WindowsLineFeedInputStream` now treats CR, LF, and CRLF as logical line
separators and emits exactly one CRLF for each. A one-byte lookahead
preserves
the byte following a lone CR, while the existing option to add a final line
ending at EOF continues to work without adding a duplicate CRLF.
## Root cause
The previous stream converted a bare LF to CRLF and recognized an existing
CRLF, but passed a CR not followed by LF through unchanged. As a result,
filtering the CR-only source from the issue reproducer still left CR-only
line
endings in the assembled file despite the requested `crlf` setting.
Unit tests cover lone and trailing CRs, consecutive CRs, and mixed CR/LF/CRLF
input. The existing Windows-line-ending Invoker project now also generates a
CR-only resource during setup, avoiding source-control newline conversion,
and
verifies the assembled bytes exactly.
## Compatibility and verification
- Maven 3.6.3 with Java 8:
`mvn -DminimalMavenBuildVersion=3.6.3 -Prun-its clean verify` passed with
271 unit tests and all 150 Invoker builds.
- Maven 3.9.16 with Java 21:
`mvn -Prun-its clean verify` passed with 271 unit tests and all 150 Invoker
builds.
- Maven 4.0.0-rc-5 with Java 21: all 271 unit tests passed, and the focused
Invoker run containing this regression passed. The full Invoker run passed
145 of 150 projects; the remaining five are unrelated parent-cycle fixtures
also failing on `master`.
Before the implementation change, the new focused unit coverage failed for
all four CR-only/mixed-ending cases.
Following this checklist to help us incorporate your
contribution quickly and easily:
- [x] Your pull request should address just one issue, without pulling in
other changes.
- [x] Write a pull request description that is detailed enough to understand
what the pull request does, how, and why.
- [x] Each commit in the pull request should have a meaningful subject line
and body.
Note that commits might be squashed by a maintainer on merge.
- [x] Write unit tests that match behavioral changes, where the tests fail
if the changes to the runtime are not applied.
This may not always be possible but is a best-practice.
- [x] Run `mvn verify` to make sure basic checks pass.
A more thorough check will be performed on your pull request automatically.
- [x] You have run the integration tests successfully (`mvn -Prun-its
verify`).
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [x] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [ ] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
--
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]
