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
Right now StatCollectors are only provided the module's path, directory, and the git project's root directory. While this allows us to write many types of Collectors, it limits Invert in a few ways:
Collectors don't have information about the dependency graph, plugins or configurations available to it. This means that these project level collectors have no way of doing any sort of decisioning based on that information.
In large projects, the most expensive part of running Invert for a Gradle project is the resolving of dependencies and configurations. If this was instead done as a step, and then StatCollectors could be run separately (outside of leveraging Gradle tasks for caching/parallelization) it would make the experience of authoring collectors much faster.
Supporting other Build Systems. We've proven that Invert can be be used with BAZEL, cmake and probably most any build system. (Make Invert more build system agnostic #29)
Right now
StatCollectors are only provided the module's path, directory, and the git project's root directory. While this allows us to write many types of Collectors, it limitsInvertin a few ways:StatCollectors could be run separately (outside of leveraging Gradle tasks for caching/parallelization) it would make the experience of authoring collectors much faster.Invertcan be be used withBAZEL,cmakeand probably most any build system. (Make Invert more build system agnostic #29)