Firstly, thanks for this really excellent PR. The mermaid graphs are much clearer than the GraphViz SVGs.

graphDump and graphUpdate are currently being registered in a few different places, like "base" plugins. We could instead create a new plugin to automatically register them, or register them once from the root project with allprojects or keep it like this for now.

Each module should have a dependency graph unless there's a special reason not to, for this reason allprojects makes sense to me. Put another way, when adding a new module it should have to explicitly opt-out of having a module graph generated for it.

There is no CI validation, meaning any change in the hierarchy of dependency might go unnoticed. Do we want an extra validation step? If so, we could also add a workflow step to automatically update the README.md files like we do for screenshots.

Sounds good to me.

This change should be documented somewhere. The Modularization learning journey is the most obvious place to do this. Changes:

• Update the modularization graph example to use mermaid instead of the current GraphViz SVG
• Document the graph format - what the colors/lines mean
• Document the graphDump and graphUpdate commands
• Document the CI workflow

I've added a RootPlugin that is now responsible to register the graph related tasks on all sub modules.

For the CI validation step, I've just copy/pasted the dependency graph block and adapted it to the graphs, but I feel like this should probably need a refactor. For instance, having an early "validation" job that takes care of these kind of update, and only after that, we execute the build/test/androidTest jobs. But it is probably out of the scope of this PR.

I still need to test this (for example if new modules are added or deleted)

• Update the modularization graph example to use mermaid instead of the current GraphViz SVG

Any suggestion? Should we try to map the current svg as close as possible?

• Document the graph format - what the colors/lines mean

Do you think of documenting this in the same document?

• Document the graphDump and graphUpdate commands

I'm not sure if it makes sense to document both of them. graphDump is an internal (intermediate) tasks that devs should probably never execute themselves. Only graphUpdate seems useful to document. Where would you want it documented exactly? IIn the Modularization learning journey docs (under which item)?

• Document the CI workflow

I don't think workflows are currently documented anywhere. Any suggestion?

Any suggestion? Should we try to map the current svg as close as possible?

Yes, I would do that. The goal of that chart is to demonstrate the different types (:app, :feature, :core). It doesn't, and shouldn't show every module.

Do you think of documenting this in the same document?

Yes, unless you can think of a more suitable place? If it was easy to add a legend to each module graph then that could be a better option.

Only graphUpdate seems useful to document. Where would you want it documented exactly? IIn the Modularization learning journey docs (under which item)?

Let's add a section "Module graphs" at the end and mention:

• Each module has its own README containing a module graph, link to the app module as an example
• When module dependencies change, the module graphs are automatically updated, link to the CI workflow
• You can run the updates yourself by running the graphUpdate command

I don't think workflows are currently documented anywhere. Any suggestion?

As above.

Happy to do any/all of this if you want to delegate to me.

as an alternative: dorongold/gradle-task-tree#41 (comment)

https://gist.github.com/OleksandrKucherenko/58478be9d17de80617ccabb6977325ea

https://github.com/OleksandrKucherenko/dependencies.graphviz

Hi @OleksandrKucherenko thanks for your input but this has nothing to do with task graphs.
If you want to discuss module graph, there is already a discussion open here: #1554

Hi @OleksandrKucherenko thanks for your input but this has nothing to do with task graphs.
If you want to discuss module graph, there is already a discussion open here: #1554

Yep, I notice that too late.

Check another comment for more related to the dependencies graph.

Colors

Do you want to reuse the colors of the SVG or something like that (or something different)?

• #536DFE Android application
• #3BD482 Android library
• #607D8B Android test
• #7F52FF JVM

Types of modules

Here is my attempt at re-creating the SVG, without trying to go too far with invisble block to try mimic-ing the original layout.

As you can see, there are not differences between regular libraries and "features". Do we want to display them differently? In this case, I can adapt the plugin code to look for nowinandroid.android.feature plugin id instead.

graph TB
  subgraph :core
    direction TB
    :core:data[data]:::android-library
    :core:database[database]:::android-library
    :core:model[model]:::jvm
    :core:network[network]:::android-library
    :core:ui[ui]:::android-library
  end
  subgraph :feature
    direction TB
    :feature:topic[topic]:::android-library
    :feature:foryou[foryou]:::android-library
    :feature:interests[interests]:::android-library
    :feature:foo[...]:::android-library

  end
  :app[app]:::android-application

  :app -.-> :feature:foryou
  :app -.-> :feature:interests
  :app -.-> :feature:topic
  :core:data ---> :core:database
  :core:data ---> :core:network
  :core:database ---> :core:model
  :core:network ---> :core:model
  :core:ui ---> :core:model
  :feature:topic -.-> :core:data
  :feature:topic -.-> :core:ui

classDef android-application fill:#536DFE,stroke:#fff,stroke-width:2px,color:#fff;
classDef android-library fill:#3BD482,stroke:#fff,stroke-width:2px,color:#fff;
classDef jvm fill:#7F52FF,stroke:#fff,stroke-width:2px,color:#fff;

Legends

something very simple

graph TB
  application:::android-application -. implementation .-> feature:::android-library
  library:::android-library -- api --> jvm:::jvm

classDef android-application fill:#536DFE,stroke:#fff,stroke-width:2px,color:#fff;
classDef android-library fill:#3BD482,stroke:#fff,stroke-width:2px,color:#fff;
classDef jvm fill:#7F52FF,stroke:#fff,stroke-width:2px,color:#fff;

or a more complex wiht real names?

graph TB
  :app[:app]:::android-application
  :feature:topic[:feature:topic]:::android-library
  :app -. implementation .-> :feature:topic

  :core:database[:core:database]:::android-library
  :core:model[:core:model]:::jvm
  :core:database -- api --> :core:model

classDef android-application fill:#536DFE,stroke:#fff,stroke-width:2px,color:#fff;
classDef android-library fill:#3BD482,stroke:#fff,stroke-width:2px,color:#fff;
classDef jvm fill:#7F52FF,stroke:#fff,stroke-width:2px,color:#fff;

Docs

## Module graphs

Each module has its own `README.md` file containing a module graph (e.g. [`:app` module graph](../app/README.md#module-dependency-graph)).  
When modules dependencies change, module graphs are automatically updated by the [Build.yaml](../.github/workflows/Build.yaml) workflow.  
You can also manually update the graphs by running the `graphUpdate` task.

Colors
There's not much contrast between some of the colors. We could use this pastel color scheme from some of the other Android sample repositories:

val PastelRed = Color(0xFFFFADAD)
val PastelOrange = Color(0xFFFFD6A5)
val PastelYellow = Color(0xFFFDFFB6)
val PastelGreen = Color(0xFFCAFFBF)
val PastelBlue = Color(0xFF9BF6FF)
val PastelMauve = Color(0xFFA0C4FF)
val PastelPurple = Color(0xFFBDB2FF)
val PastelPink = Color(0xFFFFC6FF)

Types of modules

Looks good. I would remove the :sync block as it's not important for understanding the module types.

Yes to displaying the feature modules differently, just choose any unallocated color from the above theme.

Legends

Simple looks good

Docs

Looks great 👍

I've updated the color mapping with this:

graphUpdate is now documented in ModularizationLearningJourney.

Once again, thanks for all your hard work here. I filed a follow up feature request #1962 so this PR could be merged without any further delay.