Build live dependency graphs for Spine modules

[yevhenii-nadtochii]

With the growing number of Spine modules, it becomes harder to track how they relate to each other. We need to build a dependency tree for:

1. Each Spine module separately to know which other modules it uses.
2. The whole SDK to have a big picture.

Those graphs should always be up-to-date and updated automatically. For example, when a changeset modifies module dependencies, then module's and SDK's graphs should be updated as well.

Requirements:

1. We are going to start only with Spine modules. These are artifacts whose Maven coordinates begin with io.spine prefix. Further, other dependencies can also be included.
2. Dependencies should be gathered on a per-module basis. A single repository can have multiple modules, thus producing multiple artifacts, each with its own dependencies.
3. A module can have multiple configurations, and we are going to examine all of them. If a configuration can be resolved, it should be resolved in advance. DependencyWriter does something similar to prepare POM report.
4. In a graph node we would like to see:
   4.1. Artifact name.
   4.2. Actually used and requested versions.

What we have now:

1. GitHub provides some sort of dependency graph in Insights / Dependency graph tab. It is built on a per-repository basis and represents a list of dependencies fetched from the present POM file.
2. IDEA builds diagrams, including a dependency graph. Under Gradle tab, one can select any module and click Show Diagram / Gradle dependecies. It builds something that is much closer to what we need. It lacks versions, but displays both direct and transitive dependencies from all configurations.

Tools that can be helpful:

1. Graphviz and Graphviz Online.
2. diagrams.net.
3. yEd Live.

For example, IDEA can easily export a diagram to any of the above web editors.

[yevhenii-nadtochii]

@alexander-yevsyukov @armiol Please take a look.

[alexander-yevsyukov]

It's a good start, but the Requirements section needs to be re-formulated. Let's have them as User Stories. It may narrow down the focus on what we need.

[alexander-yevsyukov]

Also, let's try to formulate our goals first, and then go to the discovery of the implementation options.

We need a Ubiquitous Language and one or, probably, more bounded contexts.

[alexander-yevsyukov]

Name the problems we have now. One of them is that we have to update dependency reports on the developer's workstations. It takes human time, which can be handled by computers.

Another problem: we observe dependencies on different versions form time to time. It makes the resulting configurations less predictable.

Have a look around. Talk to people. You'll find other problems we need to address.