Add per-resource nonFilteredFiles glob config and gracefulBinaryHandling option

[gnodet]

Problem

maven-resources-plugin exposes <nonFilteredFileExtensions> for bypassing text filtering on binary files, but this is insufficient for projects that:

• Have extension-less binary files (test keystores, generated fixtures)
• Want path-based exclusions (e.g. all files under src/main/resources/certs/)
• Want to be surgical per <resource> block rather than globally

See #303 for a concrete user report.

Proposed Solution

Once maven-filtering adds List<String> nonFilteredFiles to Resource (companion issue), expose it in ResourcesMojo and TestResourcesMojo as:

Per-resource config (primary — per <resource> block)

<resource>
  <directory>src/main/resources</directory>
  <filtering>true</filtering>
  <nonFilteredFiles>
    <nonFilteredFile>**/*.p12</nonFilteredFile>
    <nonFilteredFile>**/*.jks</nonFilteredFile>
    <nonFilteredFile>**/certs/**</nonFilteredFile>
    <nonFilteredFile>binary-file</nonFilteredFile>
  </nonFilteredFiles>
</resource>

Global opt-in graceful binary fallback (safety net)

Add a <gracefulBinaryHandling> boolean parameter (default false) at the Mojo level, propagated to MavenResourcesExecution.setGracefulBinaryHandling(true). When enabled, files that cause MalformedInputException during filtering are copied as-is with a WARN log rather than crashing the build.

<configuration>
  <gracefulBinaryHandling>true</gracefulBinaryHandling>
</configuration>

See also

• Companion issue in maven-filtering to add the underlying Resource.nonFilteredFiles field and the graceful fallback flag
• [MRESOURCES-302] Upgrade commons-io:commons-io to 2.16.0 #303 — original PR (to be superseded by this feature)

[desruisseaux]

With the new <source> element in Maven 4, we could do like below:

<sources>
  <source>
    <lang>resources</lang>
    <directory>src/main/resources</directory>
    <stringFiltering>false</stringFiltering>
    <includes>
      <include>**/*.p12</include>
      <include>**/*.jks</include>
      <include>**/certs/**</include>
      <include>binary-file</include>
    </includes>
  <source>
  <source>
    <lang>resources</lang>
    <directory>src/main/resources</directory>
    <stringFiltering>true</stringFiltering>
    <excludes>
      <exclude>**/*.p12</exclude>
      <exclude>**/*.jks</exclude>
      <exclude>**/certs/**</exclude>
      <exclude>binary-file</exclude>
    </excludes>
  <source>
</sources>

I think that the resource plugin has not yet been updated for supporting fully the <source> elements. Maybe it could be an approach?

[gnodet]

The underlying library changes (new nonFilteredFiles glob field on Resource and the opt-in gracefulBinaryHandling flag on MavenResourcesExecution) are implemented in apache/maven-filtering#395, which in turn fixes apache/maven-filtering#394. This issue tracks the maven-resources-plugin config exposure.

[gnodet]

Thanks for the suggestion! The <source> approach is elegant for Maven 4 and worth pursuing as a follow-up, but it operates at a different layer than what PR apache/maven-filtering#395 addresses.

PR#395 adds the underlying primitives in maven-filtering itself — nonFilteredFiles glob patterns on Resource and the gracefulBinaryHandling flag on MavenResourcesExecution. Whatever syntax the plugin exposes (whether <nonFilteredFiles> blocks for Maven 3 compatibility, or <source stringFiltering=false> for Maven 4), it needs to map down to something in the filtering library. nonFilteredFiles is precisely that mapping point.

The <source>-based approach also doesn't cover gracefulBinaryHandling (the opt-in fallback for MalformedInputException), which is a separate concern.

So I'd see the two as complementary: PR#395 provides the library primitive; a follow-up maven-resources-plugin PR could expose both <nonFilteredFiles> (Maven 3 compat) and the <source stringFiltering=false> pattern (Maven 4 idiomatic). Would that work for you?

[gnodet]

PR #534 adds an integration test and improves the binary-filtering error message to mention <nonFilteredFiles> alongside nonFilteredFileExtensions.

Key finding: no code change was needed in the mojo — maven-filtering's Resource POJO already has nonFilteredFiles with getter/setter, and Maven's plugin configurator injects it automatically from the plugin <configuration> block.

Note: <nonFilteredFiles> must be configured in the plugin's <configuration><resources> block, not in <build><resources>, because the POM model's <resource> element doesn't define this child element.