Correctly defined resources for gradle subproject, which is outside of root project git structure, are silently ignored

[krzysztofgenge]

What version of OpenRewrite are you using?

I am using:

• OpenRewrite v8.42.0
• Gradle plugin v6.29.0
• [org.openrewrite.recipe:rewrite-migrate-java v2.31.0

How are you running OpenRewrite?

I use Gradle plugin. I created a sample structure which replicates our issue

custom-path/
├── subproject2/
│   ├── src
│   ├── resources
│   ├── build.gradle
├── root-project/
│   ├── .git <- !!This git repo directory causes the subproject2/resources not being traversed. No recipes are applied for it!! 
│   ├── build.gradle
│   ├── settings.gradle
│   ├── subproject1/
│   │   ├── src
│   │   ├── resources
│   │   ├── build.gradle

the problem shows when the root-project contains a git repository and one of the subprojects is not a subfolder of the root-project. In the above example subproject2 is under custom-path next to root-project.

Can you share your configuration so that we can rule out any configuration issues?

Is your project public? If so, can you share a link to it?

I created a dummy project which demonstrates the issue - custom-path.zip

What is the smallest, simplest way to reproduce the problem?

Unpack the sample project go to root-project directory and execute:

git init
gradle rewriteDryRun -Drewrite.activeRecipe=com.yourorg.TestXmlRecipeRange

What did you expect to see?

I expected to see log that subproject2 resources are parsed e.g.
These recipes would make changes to ../subproject2/resources/test-subproject2.xml
and the changes are present in the generated rewrite.patch file.
I would expect it behaves the same as for java files

What did you see instead?

When .git repo folder is in root-project directory the resources for subproject2 are ignored (the java files for that project are picked up correctly)
When .git repo folder is not in root-project directory all the files are correctly parsed.
See the attached screenshot that displays the result of both executions:

What is the full stack trace of any errors you encountered?

Please see the above screenshot and sample project. No errors, the resource path for subproject2 is ignored when .git repo is present on root-project.

##Possible root cause
Maybe the problem is somehow related with this logic https://github.com/openrewrite/rewrite-gradle-plugin/blob/main/plugin/src/main/java/org/openrewrite/gradle/isolated/DefaultProjectParser.java#L129

[shanman190]

So I'm trying to understand why someone would have or want a project layout like this?

Gradle -- natively speaking -- doesn't allow for a subproject directory to be outside of the project directory. However, in the example it's abusing the projectDir property to relocate the project to a directory outside of the Gradle project itself and in the case of this issue outside of the Git repository as well.

// Specify the directory for subproject2
project(':subproject2').projectDir = file('../subproject2')

I wouldn't think that Gradle proper would desire for users to do this, but unfortunately with the level at which this particular change is happening there aren't many ways to prevent this from being done within the Gradle distribution.

And then as far as the directory being outside of the Git repository, that additional feels weird as the Gradle build would be broken on a brand new clone as the project directory is checked to actually exist.

[latusikl]

I think that subprojects outside the rootProject directory are still common in the flat project structure. Gradle still support that and reverted deprecation of these features in 7.4 as it is quite common among the community where we have large multi-module project that was/is e.g. Eclipse-based. A while ago, there were some discussions about that:

• Deprecate including sub-projects from outside the root project directory gradle/gradle#13891
• Provide alternative for flat project structure gradle/gradle#18644

For me, the usage of projectDir here seems to correspond to what you can achieve with includeFlat, so I wouldn't treat it as an abuse

Regarding different repositories for the project that are large enough, it can be the opposite approach to a monorepo when you have different teams working on the particular subproject. I agree this can require additional configuration or custom logic to run the project after cloning. On the other hand you may not face some of the monorepo challenges.

[shanman190]

I can understand the Eclipse-like project layout, but that layout AND also outside of the Git repository seems odd. The code in question should work just fine with an includeFlat style repository layout as long as the Git directory was also at the same level of the projects themselves. It's only when that's not the case that things seemingly fall flat.

[latusikl]

I can agree that the layout presented here isn't quite widespread. However, abstracting from the layout itself, I think that the problem can also be presented in a different way. Like: Providing a choice about whether to treat the root of the git repository as a build directory or be limited to what is configured on the Gradle project and sticking to the root project directory.

From what I understand, with a current approach, at least for resources (DefaultProjectParser.java#L870), the parser will look for the project resources within the whole repository, not only within the project-configured resources. Having a way to control that would help with the presented layout, but abstracting from the layout itself searching for project resources outside it within the whole repository may simply not always be what is desired.