Support exotic non standard Gradle project structures

[mezpahlan]

Carrying on the discussion from here. I plan to raise a PR to support exotic / non standard Gradle projects. These are defined by Gradle projects whose sub projects are not descendants of the root project (in the File system sense). This is a non standard, but valid, layout in the Gradle sense.

Yes it is an edge case but there are no special instructions in AMD to state compatibility of Gradle project layouts so I feel we should support these, still valid, set ups.

A "traditional" Gradle project will look like this:

my-app <-- projectRootDir & gitRootDir
|
-- .git
|
-- module-1
|
-- module-2
|
-- module-3
|
-- settings.gradle.kts

The .git folder is a child of the my-app folder on the file system and thus the my-app folder is the gitRootDir. There are no customisations in settings.gradle.kts other than to include the modules module-1, module-2, and module-3. Gradle will also see my-app as the projectRootDir. This is what most Android projects look like and is a fine and sensible layout to assume.

However I came across this setup at work:

android-project <-- gitRootDir
|
-- .git
|
-- diagrams
|
-- ci
|
-- proposals
|
-- my-app <-- projectRootDir
    |
    -- settings.gradle.kts
|
-- common
    |
    -- module-1
    |
    -- module-2
    |
    -- module-3

By instructing settings.gradle.kts where to look on the File system for the sub projects this type of layout is valid. It is certainly non standard, I will admit 😆 .

I think I have tracked the issue down to the init block in ProjectGraph where we build up a relationship between the Gradle project graph and the File system graph (later to be used as the Git graph). If we are in a non standard Gradle project we will start to see ".." entries in the sections that we need to remove otherwise we start seeing false negatives in the detection. An example of the changes look like this.

Obviously I will add tests in a proper PR but this highlights the issue and opens it up for discussion.