rzo1 opened a new pull request, #334:
URL: https://github.com/apache/maven-filtering/pull/334
Fixes #333. Downstream report: apache/maven-resources-plugin#471.
## Problem
When two `<resource>` entries cover the same source directory — one with
`filtering=true` plus a narrow `<include>`, the other with `filtering=false`
plus `<include>**</include>` — the placeholder in the file selected by the
filtered entry is no longer replaced. The literal `${...}` text remains.
Bisect lands the regression on
[1371dcf](https://github.com/apache/maven-filtering/commit/1371dcf66147877471c02f3bbeec8fed7b9a1910)
(MSHARED-1216, "Use a caching output stream when filtering resources").
That commit removed the `boolean overwrite` parameter from
`FilteringUtils.copyFile` and the timestamp-based "don't clobber a fresher
destination" gate that came with it. Every write now goes through
`CachingOutputStream` / `CachingWriter` unconditionally if the bytes
differ, so an unfiltered second `<resource>` entry overwrites the
filtered first entry's output.
3.3.1 produced the "first entry wins" semantic as a side effect of that
gate; 3.3.2+ silently lost it. Pinning `maven-resources-plugin` to 3.3.1
is the current downstream workaround.
## Change
`DefaultMavenResourcesFiltering` now tracks destination paths already
written within a single `filterResources(...)` call and skips subsequent
writes that would land on the same path. Explicit opt-in
(`MavenResourcesExecution.setOverwrite(true)`, i.e.
`ChangeDetection.ALWAYS`) keeps the previous "second entry clobbers"
behaviour for callers that relied on it. The existing flatten-collision
policy is intentionally left untouched — a duplicate flattened name still
hits the warn-or-throw path, since that case is conceptually different.
No public API surface changes.
---
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.
- [ ] You have run the integration tests successfully (`mvn -Prun-its
verify`). _N/A — this repo defines no `run-its` profile._
--
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]
