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
Currently we have two different implementations for computing dependencies.
Module stats computes shallow dependencies from explicit build file declarations.
Skippy uses SerializableDependencyGraph, which uses a subset of configurations and appears to also only just be shallow dependencies.
A new solution would be to unify these solutions and use the fully resolved graph for both. Using focus's approach seems good. We could then make a task that writes these to an output file and then aggregate them in module and skippy tasks. This would also obviate the need for declaring an explicit set of configurations to consume, as we could dynamically consume all of them.
The text was updated successfully, but these errors were encountered:
When we load all the json files in the later tasks. That should plug in easily to the jgraph building we already do in module stats, and easy enough to replicate (either with jgraph or with guava's graph support) in skippy
Currently we have two different implementations for computing dependencies.
SerializableDependencyGraph
, which uses a subset of configurations and appears to also only just be shallow dependencies.A new solution would be to unify these solutions and use the fully resolved graph for both. Using focus's approach seems good. We could then make a task that writes these to an output file and then aggregate them in module and skippy tasks. This would also obviate the need for declaring an explicit set of configurations to consume, as we could dynamically consume all of them.
The text was updated successfully, but these errors were encountered: