Extending Steep through plugins

Overview

Steep can be extended through plugins. Each plugin is a Kotlin script with the file extension .kt or .kts. Inside this script, there should be a single function with the same name as the plugin and a signature that depends on the plugin type. Function interfaces are described in the sub-sections below.

All plugins must be referenced in the plugins/common.yaml file. This file is an array of descriptor objects with at least the following properties:

PropertyTypeDescription
name
(required)		stringA unique name of the plugin (the function inside the plugin’s script file must have the same name)
type
(required)		stringThe plugin type. Valid values are: initializer, outputAdapter, processChainAdapter, processChainConsistencyChecker, and runtime.
scriptFile
(required)		stringThe path to the plugin’s Kotlin script file. The file should have the extension .kt or .kts. The path is relative to Steep’s application directory, so a valid example is conf/plugins/fileOrEmptyList.kt.
version
(optional)		stringThe plugin’s version. Must follow the Semantic Versioning Specification.

Specific plugin types may require additional properties described in the sub-sections below.

Plugins are compiled on demand when Steep is starting. This can take some time depending on the number of the plugins and their size. For faster start times, you can configure a persistent compiled plugin cache. Steep updates this cache on startup when it has first compiled a script or when it detects that a previously compiled script has changed. On subsequent startups, Steep can utilize the cache to skip compilation of known plugins and, therefore, to reduce startup time.

Parameter injection

For compatibility reasons, the plugin function signatures are not fixed. Whenever a plugin function is called, its arguments are injected based on their type. For example, if the function requires an instance of io.vertx.core.Vertx, such an object will be passed. This is independent of where this argument appears in the parameter list. In the function signatures described above, the Vert.x instance is always the last parameter, but actually, it could be at any position and the injection mechanism would still work.

This feature allows us as Steep developers to add new parameters in the future to the function signatures without requiring all users to change their plugins. It also allows plugin developers to specify parameters in any order and to even leave out parameters if they are not needed. For example, a process chain adapter could also have the following signature:

fun myProcessChainAdapter(workflow: Workflow)

Note that a parameter can only be injected into a plugin of a certain type, if it is described in the function signature of this plugin type above. For example, the function signature of a runtime plugin does not specify a workflow, so a workflow cannot be injected. Trying to define a runtime plugin with such a parameter will result in an error.

Using a template engine
Initializers