Yes, this was my intention. In our case, the required additional
classes can be determined dynamically based on configuration. It makes
sense for the code that does this determination to live with the
runnable rather than the controller.
-Martin
On 01/17/2017 09:08 PM, Andreas Neumann
I guess the difference is decoupling of the preparer from the runnable.
Martin's approach makes it a property of the runnable itself, so the
preparer can derive this information. That is, I can modify my runnable
without having to modify my invocation of the preparer.
Thoughts?
-Andreas.
On
Hi Martin,
Is it not doable via the TwillPreparer.withDependencies method?
Terence
On Tue, Jan 17, 2017 at 2:56 PM, Martin Serrano wrote:
> Team,
>
> I have some untraceable dependencies for one of my runnables. It occurs
> to me that preparing and launching the runnable
Team,
I have some untraceable dependencies for one of my runnables. It occurs
to me that preparing and launching the runnable is not always the best
place to define these dependencies (using withDependences method). The
runnable itself will always have these deps (there is static xml