DefaultArchetypeFilesResolver.findOtherResources(level, files, sourcesFiles, languages) never applies its computed include patterns

[krishna3554]

Summary

The 4-arg overload DefaultArchetypeFilesResolver.findOtherResources(int level, List<String> files, List<String> sourcesFiles, String languages) builds an includes list from the directories of the given sources files - and then never applies it to the scanner. The constructed patterns are abandoned, scanner.setIncludes(...) is never called, and the scan therefore returns every non-language file in files, regardless of the source-derived directory selection.

Static-analysis finding against current main; verified by code reading only.

Location

• File: archetype-common/src/main/java/org/apache/maven/archetype/common/DefaultArchetypeFilesResolver.java
• Function: findOtherResources(int, List, List, String) (~lines 103-127):

Set<String> selectedDirectories = new HashSet<>();
List<String> includes = new ArrayList<>();

for (String sourcesFile : sourcesFiles) {
    String directory = PathUtils.getDirectory(sourcesFile, level - 1);
    if (!selectedDirectories.contains(directory)) {
        includes.add(directory + "/**");
    }
    selectedDirectories.add(directory);
}

scanner.setExcludes(languages);

List<String> result = scanner.scan(files);   // includes never handed to scanner

Problem

Compare with the sibling 3-arg overload in the same class (~lines 82-100), which builds its include pattern identically and then correctly calls:

scanner.setIncludes(includes.toString());

The 4-arg overload constructs a List<String> of patterns but never passes it (the plexus-utils ListScanner used here has no list-valued setter call made; at minimum the list would need to be joined and set). As written:

1. The sourcesFiles parameter has no effect on which files are returned.
2. "Other resources" includes all files except those matching the language excludes — including files living outside the source directories the caller explicitly scoped to.
3. The dead includes variable is strong evidence this is an accidental omission rather than intended behavior.

Note the same file's findOtherSources(int, ...) also builds includes and does call scanner.setIncludes(...), reinforcing the copy-drift diagnosis.

Trigger / Reproduction

Based on static analysis; no runtime run performed. Call create-time archetype generation from an existing project where sourcesFiles points at e.g. src/main/java/com/foo/App.java with level=3: instead of restricting "other resources" to src/main/resources/com/foo/**-style companion directories, the resolver returns every resource in the project tree (minus excluded language extensions).

Expected Behavior

The scanned result should be limited to files under the directories derived from sourcesFiles, consistent with the method's contract and the sibling overloads.

Actual Behavior

All non-excluded files are returned; the computed include patterns are discarded.

Impact

Archetype creation from existing projects pulls unrelated resources into the generated archetype (or mislabels packaged vs unpackaged content downstream), producing bloated or incorrect archetypes whose contents depend only on the global excludes rather than the caller's source scoping.

Suggested Direction

Join the collected patterns and apply them, mirroring the 3-arg overload:

scanner.setIncludes(String.join(",", includes));

(or the separator ListScanner expects), plus a regression test asserting that a file outside any sources-file directory is not returned.

Evidence

• Dead includes construction quoted above; contrast with both sibling methods that do apply their patterns.
• Zero prior issues mention this method (search/issues?q=findOtherResources → 0), so it appears unreported.