Fix maven pom parent child relationships

[csasarak]

Overview

When scanning a directory with a package (A) that declares another package (B) to be its parent, if the parent (B) is also detected in the POM closure code we wouldn't report (A) as a target because it is no longer a root package - it's a child POM of (B).

This is confusing to users because it's possible for the top-level maven package in a directory to not be found as a target if its parent is included in a local subdirectory. This was discovered in a project where the .m2 directory was a subdirectory of the scanned directory. If .m2 weren't present, the top-level would be a target (maven@./) but if it were present it would not be.

This code changes the CLI so what we only establish that parent-child relationship if (A) has (B) as a parent and (B) also declares (A) as a submodule. The consequences of this for existing projects are that we may list more targets for analysis than we did before in the case described above.

Acceptance criteria

We should consider a maven package a target even if its parent also exists in the scanned directory unless the parent declares that package as a submodule.

Testing plan

I have attached a minimal example which demonstrates the problem. The example uses .m2 as the directory, but it could be named anything or located anywhere in the project.

You can also create an example by finding a minimal spring boot project, running mvn compile to make sure it has all deps and then copying ~/.m2 into the project root.

Risks

The only risk I can think of is that some customers may see the number of scanned targets increased, though the conditions that this bug appeared in are probably uncommon.

Metrics

None

References

• _ANE-1007

Checklist

• I added tests for this PR's change (or explained in the PR description why tests don't make sense).
• If this PR introduced a user-visible change, I added documentation into docs/.
• If this change is externally visible, I updated Changelog.md. If this PR did not mark a release, I added my changes into an # Unreleased section at the top.
• If I made changes to .fossa.yml or fossa-deps.{json.yml}, I updated docs/references/files/*.schema.json. You may also need to update these if you have added/removed new dependency type (e.g. pip) or analysis target type (e.g. poetry).

[spatten]

This looks good to me!