fix: initialize Resource includes/excludes to empty lists - #399

Good direction — eagerly initializing includes / excludes removes a whole class of NPE hazards and simplifies the downstream code.

One gap: setIncludes(List) and setExcludes(List) still accept null, which would re-nullify the field and make the removed null-checks in DefaultMavenResourcesFiltering.setupScanner() / debug-message block crash with an NPE.
Two options (either is fine):

1. Guard the setters: this.includes = includes != null ? includes : new ArrayList<>() (or throw NullPointerException).
2. Add @Nullable / document the contract — but then the null-checks in DefaultMavenResourcesFiltering must stay.

Option 1 is consistent with the intent of this PR.

Minor: nonFilteredFiles still uses the old null-init + lazy-init-in-addNonFilteredFile pattern. Worth aligning it in the same commit for consistency, though not blocking.

Overall the change is correct for the normal code path; just the setter hole needs closing.

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

Re-review after merge commit 3ed89bb. The merge brought in nonFilteredFiles from #395 but did not address the previous findings.

Previous findings status

Blocker: setIncludes(List) (line 46) and setExcludes(List) (line 54) still do raw this.includes = includes without null-guard. Since this PR removes all null-checks in DefaultMavenResourcesFiltering (setupScanner now calls .isEmpty() directly at line 431, debug block calls .getExcludes() directly at line 166), any caller that does resource.setIncludes(null) will trigger an NPE.

Fix either setter with:

public void setIncludes(List<String> includes) {
    this.includes = includes != null ? includes : new ArrayList<>();
}

(Same for setExcludes.)

The merge commit itself introduced no new issues.

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

Re-review after merge commit 3ed89bb. The merge of master is clean, but the primary finding from the previous review is not addressed.

Previous Finding 1 (setter null hole) — NOT ADDRESSED:
setIncludes(List) and setExcludes(List) still do this.includes = includes without a null guard. A caller passing null re-nullifies the field, making the null-check removals in DefaultMavenResourcesFiltering (both setupScanner and the debug log block) crash with NPE. This was the blocking issue from the previous review and it remains open.

Fix both setters:

public void setIncludes(List<String> includes) {
    this.includes = includes != null ? includes : new ArrayList<>();
}
public void setExcludes(List<String> excludes) {
    this.excludes = excludes != null ? excludes : new ArrayList<>();
}

Previous Finding 2 (minor — nonFilteredFiles consistency) — NOT ADDRESSED:
nonFilteredFiles still uses the old null-init + lazy-init-in-addNonFilteredFile pattern. Not blocking, but worth aligning in the same commit.

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

Re-review after 1ad9efb — all previous findings addressed.

No new issues introduced. The downstream null-check removals in DefaultMavenResourcesFiltering (debug log and setupScanner) are safe given the non-null guarantees now established in Resource.

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

Re-review after rebase (c4bca3d). Tree content identical to previously approved 1ad9efb — pure rebase, no code changes. All previous findings remain addressed.

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

Re-review after rebase (9950b2d). The PR's changes are identical to the previously approved state (1ad9efb) — only the base commit changed (master advanced). All previous findings remain addressed: setters null-guarded, nonFilteredFiles eagerly initialized, downstream null-checks correctly removed. Clean rebase, no new issues.

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