Currently, if a RuntimeStateProvider is serialized (transmitted to a different JVM), the set of required bundle identifiers is determined as:
runtimeContext.getRepository().getBundles()
.stream()
.map(RuntimeBundle::getBundleIdentifier)
.collect(Collectors.toList())When, e.g., serializing the runtime-state provider in order to execute a simple module in a separate JVM, the set of bundle identifiers may thus include way more than necessary (essentially the entire repository out of which only one simple module is required – possibly with type and annotation plugins though).
In particular, the DSL runtime context provider has the ability to look for all transitive dependencies of a simple module and only link those. That is, at least in this case, if the original bundle URI was of form x-dsl:org.genetics.Wholepipeline, the bundle URI for a simple-module execution may simply be, e.g., x-dsl:org.genertics.SortVariants – this way, many unneeded plug-ins don't have to be linked.
Currently, if a
RuntimeStateProvideris serialized (transmitted to a different JVM), the set of required bundle identifiers is determined as:When, e.g., serializing the runtime-state provider in order to execute a simple module in a separate JVM, the set of bundle identifiers may thus include way more than necessary (essentially the entire repository out of which only one simple module is required – possibly with type and annotation plugins though).
In particular, the DSL runtime context provider has the ability to look for all transitive dependencies of a simple module and only link those. That is, at least in this case, if the original bundle URI was of form
x-dsl:org.genetics.Wholepipeline, the bundle URI for a simple-module execution may simply be, e.g.,x-dsl:org.genertics.SortVariants– this way, many unneeded plug-ins don't have to be linked.