Nested projects: Enable relative path for "build.gradle" & "gradlew" in settings

[Dedeou31]

First, I would like to congratulate, your extension is GREAT 👏 👏 👏

Current behavior
As found in the documentation: "A root project (projectDir) is defined by having a gradle wrapper script at the root (gradlew or gradlew.bat)"

solution you'd like
It would be a nice feature to have settings to configure build.gradle and gradlew path.

A path relative to (projectDir):
example: ./src/tasks/

Which could be interpreted by the extension in:
$workspaceDir/src/tasks/gradlew
$workspaceDir/src/tasks/build.gradle

[badsyntax]

Hey, thanks for the feedback!

Previously this extension had the ability to automatically discover nested projects (like in your case), but I found that caused all types of issues on projects that contained test fixtures, or directories that contained nested gradle projects that aren't intended to be discovered by gradle as part of the root project, so I removed that feature.

I'm happy to go with your proposal, I'll see what I can do 👍 Can't make any promises about when I can do it though.

Some dev notes:

• To keep it simple, the setting will only accept 1 path relative to the root (eg src/tasks). There will be no change to the task names.
• Now that gradle can be configured to not use the gradle wrapper (Add support for additional gradle settings #320), remove this info from the README, and update the activation events. gradle projects should be identified by having a *.gradle file at the root of the workspace, or root of the (workspace + custom path)
• Clean up the docs on how projects are discovered
• Fix the logic for refreshing tasks on build file changes

[badsyntax]

I'm curious to understand your use-case a bit better. Why does your project contain a nested gradle project? Why is gradle not defined at the root? Just curious..

[Dedeou31]

Thank you so much for your feedback.

Because on some projects I am using a gradle plugin that only allows the build.gradle and gradlew path in certain path from the workspace root !!!

[badsyntax]

I don't fully understand that. A gradle plugin shouldn't care where the build files are located. Can you elaborate a bit?

[Dedeou31]

I cannot tell much more because I don't really know the rationale, a custom plugin that overcome gradle conventions and force the usage of those files. !!

[dhee9000]

Has there been any work done towards supporting this feature? I would be happy to submit a PR if you could point me to where changes might need to be made to enable this.

My specific use case for this would be in a react-native project where the root build.gradle is in a sub-folder for android which also happens to be where gradlew resides (the entire android app Java project is rooted at this folder).

The relative path to it would be something like one of:
./android/build.gradle
${workspaceFolder}/android/build.gradle

[badsyntax]

Not yet, I've been focusing on getting #433 out the door, after-which I'll tackle this. Due to the amount of changes in that PR, I don't want to make any other changes until it's merged.

[badsyntax]

I'm starting to think about how best to implement this feature. I'm thinking of introducing a new setting:

{
  "gradle.nestedProjects": {
    "anyOf": [
      {
        "type": "boolean",
        "description": "Processs all nested projects",
        "default": false
      },
      {
        "type": "array",
        "description": "Process specific nested projects",
        "default": []
      }
    ],
    "scope": "window",
    "default": false
  }
}

This will allow the user to:

1. set "gradle.nestedProjects": true to process all nested projects, or
2. set "gradle.nestedProjects": ["android","otherproject"] to process specific nested projects

This is nice and flexible and should cover all cases for nested projects. In most cases, option 1 will suffice. In cases where there are nested projects that should not be processed (eg test fixtures), then option 2 can be used.

[badsyntax]

Here's an example of what the task tree will look like:

To support multiple nested projects, I will display the nested project within a top-level directory node:

├── nested-project-folder1
│   ├── gradle-project1
│   │   └── task-group1
│   │       ├── task1
│   │       └── task2
│   ├── gradle-project2
│   │   └── task-group2
│   │       ├── task1
│   │       └── task2
├── nested-project-folder2
│   ├── gradle-project1
│   │   └── task-group1
│   │       ├── task1
│   │       └── task2

[badsyntax]

Added some POC code here: #487

Will try get this feature released in the next few days 👍

[dhee9000]

Looks great and the setting is well designed leaving flexibility for different use cases. Is the gradle cwd fix from #332 relevant to this?

[badsyntax]

Thanks. That PR is not really relevent. This issue is to support nested root projects. That PR is for supporting relative paths which are relative to the root projects. I still want to find a solution for that PR, I haven't given up on it yet.

[badsyntax]

PR #487 is ready to go, but my tests are failing in CI due to microsoft/vscode#98080 I will wait a couple of days to see if that bug can be fixed, and if not, i will just release with failing CI tests.

This change wasn't particularly easy. I discovered performance issues with the gradle daemons using nested projects and had to rework a bit of logic.

Thanks for your patience, i'll update this issue when i've released this feature.

[badsyntax]

This change is now released with 3.2.0.

As mentioned above you can enable nested projects via the settings:

• "gradle.nestedProjects": true to process all nested projects, or
• "gradle.nestedProjects": ["android","otherproject"] to process specific nested projects relative to workspace root.

I'm gonna close this issues, but please re-open if you find any issues.