-
Notifications
You must be signed in to change notification settings - Fork 3.5k
Description
The state of the different task managers has degraded over time as different systems have been built and intertwined. Some recent issues (stop shipping duplicate gems, duplicated work in building) show some examples of degraded state.
Ideally we would be able to take advantage of each build system's tree representation of tasks to get helpful dependency resolution. When we start invoking different build systems from other build systems we risk breaking dependency resolution unless we are very careful. For example we have cases where rake will make multiple calls to gradle via sub-processes. This breaks down gradle's ability to be efficient.
Based on the current state, an effort to standardize with the following heuristics could really help:
- For any supported/intended workflow we start with a gradle task (IE we never invoke rake/make directly unless debugging)
- Rake and make tasks should not call back in to gradle (There could be a use case for this, but we should audit and prove we are not breaking down efficiency).
Following these heuristics efforts to for example remove exogenous jruby from test runners becomes much easier as we could ensure that every top level gradle invocation has the proper dependency resolution for installing jruby and our deduplicated gem set.