At the heart of the workflow engine lies the
WorkflowComponent
. A workflow component represents
a part of a generator process. Such parts are typically model parsers,
model validators, model transformers and code generators. MWE ships with
different workflow components which should be used where suitable, but you
can also implement your own. The only thing you have to do is to implement
the
org.eclipse.emf.mwe.core.WorkflowComponent
interface:
public interface WorkflowComponent { /** * @param ctx * current workflow context * @param monitor * implementors should provide some feedback about the progress * using this monitor * @param issues */ public void invoke(WorkflowContext ctx, ProgressMonitor monitor, Issues issues); /** * Is called by the container after configuration so the * component can validate the configuration before invocation. * * @param issues - * implementors should report configuration issues to this. */ public void checkConfiguration(Issues issues); }
The invoke()
operation performs the actual
work of the component. checkConfiguration
is used
to check whether the component is configured correctly before the workflow
starts. More on these two operations later.
A workflow description consists of a list of configured WorkflowComponents. Here is an example:
<workflow> <component class="my.first.WorkflowComponent"> <aProp value="test"/> </component> <component class="my.second.WorkflowComponent"> <anotherProp value="test2"/> </component> <component class="my.third.WorkflowComponent"> <prop value="test"/> </component> </workflow>
The workflow shown above consists of three different workflow components. The order of the declaration is important! The workflow engine will execute the components in the specified order. To allow the workflow engine to instantiate the workflow component classes, WorkflowComponent implementations must have a default constructor.
A workflow is just a composite implementation of the
WorkflowComponent
interface. The
invoke
and
checkConfiguration
methods delegate to the
contained workflow components.
The Workflow class declares an
addComponent()
method:
public void addComponent(WorkflowComponent comp)</para>
which is used by the workflow factory in order to wire up a workflow (see next section Workflow Configuration ).
If you want your workflow components to have an ID (so that you
can recognize its output in the log) you have to implement the interface
WorkflowComponentWithID
and the
setID()
and getID()
operations. Alternatively, you can also extend the base class
AbstractWorkflowComponent
, which handles the ID
setter/getter for you.
There is another base class for workflow components called
AbstractWorkflowComponent2
. Its main feature is,
that it has a property called skipOnErrors. If set
to true
, it will not execute if the workflow issues
collection contains errors. This is convenient, if you want to be able
to skip code generation when the preceding model verification finds
errors. Note that instead of implementing
invoke(...)
and
checkConfiguration(...)
, subclasses of
AbstractWorkflowComponent2
have to implement
invokeInternal(...)
and
checkConfigurationInternal(...)
. This is
necessary to allow the framework to intercept the invocation and stop it
when there are errors in the workflow.