With #216, there is an interesting side effect, as the Main class has to be pointed out in the core call to Java, instead of being supplied by the jar manifest.
We could include the hydra api supported by core in the core distribution itself, and simply include it in the classpath for the launch command. This would ensure that there can't be a version mismatch between stages and core, except of course in the case of breaking API changes in AbstractStage. The scope for the api dependency would simply be changed to provided in the stage poms.
Basic stages would no longer require a "with dependencies" build at all, and other stages would not need to include the hydra stack in their jars.
With #216, there is an interesting side effect, as the Main class has to be pointed out in the core call to Java, instead of being supplied by the jar manifest.
We could include the hydra api supported by core in the core distribution itself, and simply include it in the classpath for the launch command. This would ensure that there can't be a version mismatch between stages and core, except of course in the case of breaking API changes in
AbstractStage. The scope for the api dependency would simply be changed toprovidedin the stage poms.Basic stages would no longer require a "with dependencies" build at all, and other stages would not need to include the hydra stack in their jars.