Fix resources exclusion in a multi-module project with git repo

[radoslaw-panuszewski]

What's changed?

Fixed the bug with resources in subproject being excluded from processing.

What's your motivation?

I have a multi-module project like this:

.
├── src
│   └── main
│       └── resources
│           └── application-root.yml
└── subproject
    └── src
        └── main
            └── resources
                └── application-subproject.yml  

And I have a custom recipe to modify some YAML. While the application-root.yml is correctly modified, the application-subproject.yml is skipped. It is reproduced in the resources in subproject committed to git are correctly processed test case.

There is already a test case rewriteRun applies recipe to a multi-project build which aims to verify this situation, but it doesn't check the case when Git repo is available. There is a different code path in OmniParser for such case and it's not reached.

I believe that I've found a bug in the code of DefaultProjectParser. When the OmniParser is created for the root project, it is configured to exclude contents of its subprojects. But when it's created for the subproject, it's still configured to exclude the root project's subprojects, so also the subproject we want to parse.

Anything in particular you'd like reviewers to focus on?

I've added the Project parameter to the omniParser(). Please verify that the updated method usages are correct.

Additional changes

There was a typo in dependencyRepositoriesDeclaredInSettings test case which caused the test to fail. I fixed it: nevVersion -> newVersion

Checklist

• [x] I've added unit tests to cover both positive and negative cases
• [ ] I've read and applied the recipe conventions and best practices
• [ ] I've used the IntelliJ IDEA auto-formatter on affected files

[timtebeek]

@travisboettcher this PR takes a slightly different approach to what you suggested in https://github.com/openrewrite/rewrite-gradle-plugin/issues/252 ; Any thoughts to share here?

[travisboettcher]

@travisboettcher this PR takes a slightly different approach to what you suggested in #252 ; Any thoughts to share here?

I don't think I have any concerns, no - this change makes sense to me. If I understand correctly, we don't need to use the existing execution context when parsing resources, since they aren't likely to reference other sub-modules. In addition, the test added seems to cover my case, so I think we're good!