Convert two existing concepts (RunTracker and the jar tool) to be subsystems.
Review Request #2081 — Created April 15, 2015 and submitted
|patricklaw, stuhood, zundel|
- The RunTracker change is straightforward.
- There is now a JarTool subsystem. But implementing this neatly
required some changes to the JVM tool machinery:
+ The old JvmToolTaskMixin is now JvmToolMixin. I.e., you don't have
to be a task to use JVM tools. Indeed, subsystems can mix this in
in order to register and bootstrap JVM tools.
+ JvmToolTaskMixin is now a thin subclass of JvmToolMixin, adapting
it for ease of use by tasks. In the future we might make all
JVM tools (compilers etc.) into subsystems and then not need
JvmToolTaskMixin at all.
+ The new JarTool subsystem does two things:
1) Bootstraps the jar tool and handles its options.
2) Actually runs the jar tool with given args in a given runner.
This interface is slightly awkward perhaps, but very reusable.
And we already pass runners around as arguments elsewhere anyway.
- Removed some clunky code in JvmToolTaskTestBase that registers options
for BootstrapJvmTools, which is not the task under test but is needed
to bootstrap tools for the task under test. Instead overrides context() to
add BootstrapJvmTools to the list of tasks the base class already clunkily
registers options for (in addition to the task under test)...
- TODO: JarTool is now tested indirectly in test_jar_task.py,
but we might want to also test the now-standalone subsystem directly.
CI passes: https://travis-ci.org/pantsbuild/pants/builds/58631095
Revision 2 (+208 -155)
Submitted as 8a656213dceaceb0588fc61c8f9d5ffd633990bf. Thanks for the reviews!