krishna3554 opened a new issue, #1020:
URL: https://github.com/apache/maven-archetype/issues/1020
## 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):
```java
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:
```java
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:
```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.
--
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]
