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 wrote:
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 Tue, Jan 17, 2017 at 5:56 PM, Terence Yim <cht...@gmail.com> wrote:
Hi Martin,
Is it not doable via the TwillPreparer.withDependencies method?
Terence
On Tue, Jan 17, 2017 at 2:56 PM, Martin Serrano <mar...@attivio.com>
wrote:
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
configuration embedded in the lib). What would folks think of the idea
of
a tagging interface that TwillPreparer would check and insert the deps
itself.
Something like:
public interface HasDependencies {
Iterable<Class<?>> dependencies();
}
This interface could be added to any implementation of TwillRunnable.
Thoughts?
-Martin
