[MRESOURCES-162] Add failOnMissingFilterValue option to fail build on unresolved filter tokens

[gnodet]

Summary

Implements the feature requested in MRESOURCES-162 (apache/maven-resources-plugin#532): a configurable option to fail the build when a filter expression cannot be resolved, instead of silently passing the placeholder through to the output.

Changes

• AbstractMavenFilteringRequest: add failOnMissingFilterValue boolean (default false, backward compatible)
• MavenResourcesExecution.copyOf(): propagate the new field
• BaseFilter.Wrapper: thread the flag to the filter reader
• InterpolatorFilterReaderLineEnding: throw IOException on unresolved token when enabled
• MultiDelimiterInterpolatorFilterReaderLineEnding: same

Behaviour

When failOnMissingFilterValue is false (default): existing behaviour unchanged — unresolved ${placeholder} is passed through as-is.

When failOnMissingFilterValue is true: any placeholder that no ValueSource can resolve throws an IOException with a message identifying the token (e.g. Unresolved filter token: '${missing.property}'). This propagates through FilteringUtils → DefaultMavenFileFilter → DefaultMavenResourcesFiltering → MavenFilteringException, causing a build failure.

Note on unresolved token detection

The plexus interpolator never returns null for unresolved expressions — it returns the original expression string (e.g. ${missing.property}). The unresolved token is detected by comparing the interpolated value to the original key string (value.equals(key.toString())).

Consumer PR

apache/maven-resources-plugin#532 exposes this as @Parameter(property="maven.resources.failOnMissingFilterValue") on the Mojo.

[gnodet-bot]

Solid implementation — opt-in, backward-compatible, properly threaded through the filter chain, and well-tested. One observation on an edge case in InterpolatorFilterReaderLineEnding.

This review was generated by an AI agent, Hermès on behalf of @gnodet.

[gnodet-bot]

Re-review after 82412c6 — the fix correctly addresses the core detection bug.

Previous finding status:

• Addressed: The null-check issue is fixed. The plexus interpolator returns the original expression for unresolved tokens (not null), and the new code detects this via value.equals(key.toString()) comparison. Both InterpolatorFilterReaderLineEnding and MultiDelimiterInterpolatorFilterReaderLineEnding are updated consistently.
• Acknowledged (non-blocking): The end != 0 behavioral asymmetry I flagged previously (unterminated tokens throw in strict mode for InterpolatorFilterReaderLineEnding but are silently passed through in MultiDelimiterInterpolatorFilterReaderLineEnding) is intentionally left as-is. This is a reasonable design choice — users opting into strict mode likely want malformed expressions flagged too.

The implementation is solid: opt-in flag, backward-compatible default, properly threaded through the filter chain, and tested for both enabled/disabled paths.

This review was generated by an AI agent, Hermès on behalf of @gnodet.