filterDependencies destructively mutates the caller's set via Iterator.remove()

[elharo]

AbstractAnalyzeMojo.filterDependencies() at line 568-573:

for (Iterator<Artifact> it = artifacts.iterator(); it.hasNext(); ) {
    Artifact artifact = it.next();
    if (!filter.include(artifact)) {
        it.remove();    // mutates the ORIGINAL set passed in
        result.add(artifact);
    }
}

This method is called multiple times on the same set with different filter arrays (lines 363-375):

ignoredUsedUndeclared.addAll(filterDependencies(usedUndeclaredWithClasses.keySet(), ignoredDependencies));
ignoredUsedUndeclared.addAll(filterDependencies(usedUndeclaredWithClasses.keySet(), ignoredUsedUndeclaredDependencies));

After the first non-empty filter removes matching entries from usedUndeclaredWithClasses, the second call operates on an already-reduced set. The "Used undeclared dependencies found:" warning listing (line 392, 394) iterates usedUndeclaredWithClasses which has been destructively modified — entries matching ignoredDependencies are silently missing from the warning output.

The same pattern applies to unusedDeclared and nonTestScope (lines 367-375).

The method should either:

1. Copy the set before iterating, or
2. Build the result without removing from the input, leaving the caller responsible for subtraction

[apoorva-01]

I've got a fix ready for this one (option 2 from your list: build the returned set instead of removing from the input, and let the callers do their own removeAll). Regression test fails on master, passes with the change, and the analyze ITs are still green.

Before I put up a PR though, I noticed #1652 is already open on the same method. It touches the empty-excludes return too, and the Javadoc it adds calls the set "mutated in place", so it kind of reads like the mutation is meant to stay. Which is the opposite of what this issue's asking for.

So I figured I'd check before stepping on it: do you still want the Iterator.remove() gone here (subtraction moved out to the callers), or is the mutate-in-place thing the intended answer and this can just be closed? If you do want it removed, happy to rebase on top of #1652 since they both poke at that same return.

[elharo]

I wouldn't work on this yet.