Apply the computed include patterns when finding other resources

[adityaanikam]

Description

The four-argument DefaultArchetypeFilesResolver.findOtherResources(int level, List<String> files, List<String> sourcesFiles, String languages) builds a list of include patterns from the directories of the given sources files, and then never applies it:

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

scanner.setExcludes(languages);      // includes never passed to the scanner
List<String> result = scanner.scan(files);

ListScanner.scan treats a missing include set as "**":

if (includes == null) {
    // No includes supplied, so set it to 'matches all'
    includes = new String[1];
    includes[0] = "**";
}

So the scan returns every file that the language excludes do not remove, and sourcesFiles has no effect on the result. Both sibling methods that build include patterns, the three-argument findOtherResources and findOtherSources, do call setIncludes.

The fix passes the list to the scanner. ListScanner already has a setIncludes(List<String>) overload, so no joining is needed. An empty sources list produces an empty pattern array, which leaves the include field unset and preserves today's behaviour, so the change is inert in that case.

Additional context and related issues

Fixes #1020.

On the effect: FilesetArchetypeCreator.createArchetype calls this once, and removes the returned files from the list it is still working through. The level three pass therefore consumed everything left, starving the later findOtherResources(2, ...) and findOtherResources(0, ...) passes. Files such as pom.xml were handed to createFileSets(..., 3, ...) and grouped by a level that does not match their depth, instead of falling to the root pass.

No files are dropped by the change: whatever the level three pass no longer claims is still matched by the root pass, whose include pattern is **.

Testing

Added testFindOtherResourcesIsRestrictedToTheSourcesDirectories to the existing TestDefaultArchetypeFilesResolver. With a sources file of src/main/java/App.java at level 3, the derived directory is src/main, so src/test/resources/AppTest.properties and pom.xml must not be returned.

Verified with a negative control: reverting only DefaultArchetypeFilesResolver.java and keeping the test makes it fail with all three files returned, which is the abandoned-includes behaviour:

expected: <[src/main/resources/App.properties]>
 but was: <[src/main/resources/App.properties, src/test/resources/AppTest.properties, pom.xml]>

mvn verify -pl archetype-common -am passes with 30 tests. The integration tests pass as well, 32 builds with no failures, which includes the create-from-project projects and both roundtrips that exercise this code path.

• Your pull request should address just one issue, without pulling in other changes.

• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.

• Each commit in the pull request should have a meaningful subject line and body.

• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied.

• Run mvn verify to make sure basic checks pass.

• You have run the integration tests successfully (mvn -Prun-its verify).

• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004