gnodet opened a new pull request, #399:
URL: https://github.com/apache/maven-filtering/pull/399
## Summary
`Resource.getIncludes()` and `getExcludes()` returned `null` by default,
forcing every
consumer to null-check before accessing the list. This led to verbose
defensive coding
scattered across call sites.
## Root Cause
`Resource.java` declared `includes` and `excludes` as package-private fields
without
initialization, so they default to `null`. The `addInclude` and `addExclude`
methods
had to lazily allocate the lists, and `DefaultMavenResourcesFiltering` had
to null-check
both in the debug-logging block and in `setupScanner`.
## Fix
- Initialize `includes` and `excludes` to `new ArrayList<>()` so getters
always return
a non-null, mutable list.
- Simplify `addInclude` / `addExclude` — remove the now-redundant null
guards.
- Clean up `DefaultMavenResourcesFiltering`:
- Debug log block: replace `resource.getExcludes() == null ? " empty " :
resource.getExcludes().toString()` with a direct `resource.getExcludes()` call.
- `setupScanner`: simplify the `if/else` chain with a ternary and drop the
outer null check on excludes.
## Tests
All 88 existing tests pass (`mvn verify`). No behavioral change — the lists
are still
mutable and `setIncludes`/`setExcludes` still accept `null` for callers that
want to
clear them.
Fixes #356
--
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]
