DependencyInfo.hashCode() violates equals/hashCode contract

[elharo]

Bug Description

DependencyInfo.hashCode() at src/main/java/org/apache/maven/plugins/war/util/DependencyInfo.java lines 87-91 violates the equals/hashCode contract.

equals() (line 83) compares only the dependency field, but hashCode() (lines 87-91) incorporates both dependency and targetFileName.

Impact

Two DependencyInfo objects with the same dependency but different targetFileName will be equals() (return true) but produce different hash codes, violating the fundamental contract and causing incorrect behavior in HashMap, HashSet, or any hash-based collection.

Code

// equals() — line 83
return Objects.equals(dependency, that.dependency);

// hashCode() — lines 87-91
public int hashCode() {
    int result;
    result = (dependency != null ? dependency.hashCode() : 0);
    result = 31 * result + (targetFileName != null ? targetFileName.hashCode() : 0);
    return result;
}

Expected behavior

hashCode() should be consistent with equals() — either include only dependency in both, or include both dependency and targetFileName in both.

[elharo]

On the fix: I chose to fix hashCode() rather than equals() for the following reasons:

1. targetFileName is mutable — it has a setter and can change after construction. Including mutable fields in equals()/ hashCode() is a well-known anti-pattern in Java: if an object is placed in a HashSet or HashMap and then mutated via setTargetFileName(), it becomes "lost" in the collection because its hash code changed after insertion.

2. equals() was deliberately written without targetFileName — this is consistent with the principle that equality should be based on the object's identity (the dependency), not its mutable metadata (the output filename).

3. Minimal, backward-compatible change — code that already relies on equals() comparing only dependency continues to work unchanged.

If the domain requires that same-dependency/different-target-filename objects be treated as distinct, then equals() should be changed and targetFileName should be made immutable (removed from the setter). But that would be a larger behavioral change than what this bug warrants.