You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Each Spine module separately to know which other modules it uses.
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:
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.
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.
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.
In a graph node we would like to see:
4.1. Artifact name.
4.2. Actually used and requested versions.
What we have now:
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.
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.
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.
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.
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:
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:
io.spine
prefix. Further, other dependencies can also be included.DependencyWriter
does something similar to prepare POM report.4.1. Artifact name.
4.2. Actually used and requested versions.
What we have now:
Insights / Dependency graph
tab. It is built on a per-repository basis and represents a list of dependencies fetched from the present POM file.Gradle
tab, one can select any module and clickShow 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:
For example, IDEA can easily export a diagram to any of the above web editors.
The text was updated successfully, but these errors were encountered: