[MASSEMBLY-947] Normalize CR line endings to CRLF - #1341
Merged
Conversation
Normalize lone carriage returns in WindowsLineFeedInputStream so all recognized line endings are emitted as CRLF. Add unit and integration coverage for CR-only and mixed line endings. Fixes apache#1154
There was a problem hiding this comment.
Pull request overview
This PR fixes MASSEMBLY-947 by ensuring that when a file set requests CRLF (<lineEnding>crlf</lineEnding> and aliases), inputs using old Mac CR-only line endings are normalized to CRLF during assembly filtering, rather than leaving bare \r unchanged.
Changes:
- Update
WindowsLineFeedInputStreamto treatCR,LF, andCRLFas line separators and emit exactly oneCRLFper logical line ending (using a one-byte lookahead for loneCR). - Expand unit coverage to include CR-only, trailing CR, consecutive CRs, and mixed CR/LF/CRLF cases.
- Strengthen the existing Invoker IT by generating a CR-only input during setup and asserting exact assembled output for both the existing and new fixture files.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| src/main/java/org/apache/maven/plugins/assembly/utils/WindowsLineFeedInputStream.java | Normalizes CR-only and mixed line separators to CRLF using lookahead and pending-byte buffering. |
| src/test/java/org/apache/maven/plugins/assembly/utils/WindowsLineFeedInputStreamTest.java | Adds targeted tests covering CR-only and mixed-ending normalization behavior. |
| src/it/projects/file-sets/multimodule-win-lineEndings/setup.groovy | Creates a CR-only resource at test runtime to avoid SCM newline conversion and reproduce the bug reliably. |
| src/it/projects/file-sets/multimodule-win-lineEndings/verify.groovy | Verifies the assembled output content exactly (including line-ending bytes) for both fixtures. |
| src/it/projects/file-sets/multimodule-win-lineEndings/child/pom.xml | Pins the parent relativePath to the shared IT parent POM for stable resolution in the IT layout. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
elharo
approved these changes
Aug 1, 2026
slawekjaranowski
approved these changes
Aug 3, 2026
slachiewicz
approved these changes
Aug 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1154.
Summary
Normalize old Mac CR-only line endings to CRLF when an assembly file set uses
<lineEnding>crlf</lineEnding>(or itswindows/dosaliases).WindowsLineFeedInputStreamnow treats CR, LF, and CRLF as logical lineseparators 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
crlfsetting.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
mvn -DminimalMavenBuildVersion=3.6.3 -Prun-its clean verifypassed with271 unit tests and all 150 Invoker builds.
mvn -Prun-its clean verifypassed with 271 unit tests and all 150 Invokerbuilds.
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:
Note that commits might be squashed by a maintainer on merge.
This may not always be possible but is a best-practice.
mvn verifyto make sure basic checks pass.A more thorough check will be performed on your pull request automatically.
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 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
you have to acknowledge this by using the following check-box.