apache / apache/maven-archetype
DefaultArchetypeFilesResolver.findOtherResources(level, files, sourcesFiles, languages) never applies its computed include patterns
- Dominant language
- Java
- Stars
- 148
- Forks
- 181
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 8
Description
## Summary
The 4-arg overload `DefaultArchetypeFilesResolver.findOtherResources(int level, List files, List 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):
```java
Set selectedDirectories = new HashSet<>();
List 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 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:
```java
scanner.setIncludes(includes.toString());
```
The 4-arg overload constructs a `List` 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:
```java
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.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start in archetype-common/src/main/java/org/apache/maven/archetype/common/DefaultArchetypeFilesResolver.java at findOtherResources(int, List, List, String), then compare its scanner setup with the sibling overloads. Add a regression test using source files and an unrelated resource to verify that only resources under derived directories are returned, and run the relevant project tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- build-system
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 82/100