summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorbkolb2007-10-12 15:30:30 (EDT)
committerbkolb2007-10-12 15:30:30 (EDT)
commita9d2581f14fe008aabf90b7bc72a5e069520df0f (patch)
treea8b2fa58e49b1d13a899aaf71d0bb70ae4dcf929
parente468cd4f8114b4eb3b887a36adc8c8ae3fb97af1 (diff)
downloadorg.eclipse.mwe-a9d2581f14fe008aabf90b7bc72a5e069520df0f.zip
org.eclipse.mwe-a9d2581f14fe008aabf90b7bc72a5e069520df0f.tar.gz
org.eclipse.mwe-a9d2581f14fe008aabf90b7bc72a5e069520df0f.tar.bz2
[206191] added reference for core
-rw-r--r--doc/org.eclipse.emf.mwe.doc/references/workflow_reference.html667
1 files changed, 667 insertions, 0 deletions
diff --git a/doc/org.eclipse.emf.mwe.doc/references/workflow_reference.html b/doc/org.eclipse.emf.mwe.doc/references/workflow_reference.html
new file mode 100644
index 0000000..0275a56
--- /dev/null
+++ b/doc/org.eclipse.emf.mwe.doc/references/workflow_reference.html
@@ -0,0 +1,667 @@
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>MWE Reference</title>
+<link rel="stylesheet" href="book.css" type="text/css">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
+<div class="chapter" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h2 class="title"><a name="workflow_reference"></a>Modeling Workflow Engine Reference</h2>
+ </div>
+ </div>
+ </div>
+ <div class="toc">
+ <dl>
+ <dt><span class="section"><a href="workflow_reference.html#workflow_refrence_introduction">Introduction</a></span></dt>
+ <dt><span class="section"><a href="workflow_reference.html#workflow_reference_workflow_components">Workflow components</a></span></dt>
+ <dt><span class="section"><a href="workflow_reference.html#workflow_reference_workflow_configuration">Workflow Configuration</a></span></dt>
+ </dl>
+ </div>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h2 class="title" style="clear: both"><a name="workflow_refrence_introduction"></a>Introduction</h2>
+ </div>
+ </div>
+ </div>
+ <p> The modeling workflow engine is a declarative configurable generator engine. It provides a
+ simple, XML based configuration language with which all kinds of generator workflows can
+ be described. A generator workflow consists of a number of so-called workflow components
+ that are executed sequentially in a single JVM. </p>
+ </div>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h2 class="title" style="clear: both"><a name="workflow_reference_workflow_components"></a>Workflow components</h2>
+ </div>
+ </div>
+ </div>
+ <p> At the heart of the workflow engine lies the WorkflowComponent. A WorkflowComponent
+ represents a part of a generator process. Such parts are typically model parsers, model
+ validators, model transformers and code generators. MWE ships with different
+ WorkflowComponents which should be used where suitable, but you can also implement your
+ own. The only thing you have to do is to implement the <code class="classname">org.eclipse.emf.mwe.core.WorkflowComponent</code> interface: </p>
+ <pre class="programlisting">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);
+
+}</pre>
+ <p> The <code class="methodname">invoke()</code> operation performs the component's actual work. <code class="methodname">checkConfiguration</code> is used to check whether the component is configured
+ correctly before the workflow starts. More on these two operations later. </p>
+ <p>A workflow description consists of a list of configured WorkflowComponents.</p>
+ <p>Here's an example:</p>
+ <pre class="programlisting">&lt;workflow&gt;
+ &lt;component class="my.first.WorkflowComponent"&gt;
+ &lt;aProp value="test"/&gt;
+ &lt;/component&gt;
+ &lt;component class="my.second.WorkflowComponent"&gt;
+ &lt;anotherProp value="test2"/&gt;
+ &lt;/component&gt;
+ &lt;component class="my.third.WorkflowComponent"&gt;
+ &lt;prop value="test"/&gt;
+ &lt;/component&gt;
+&lt;/workflow&gt;</pre>
+ <p> 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. </p>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h3 class="title"><a name="workflow_reference_workflow"></a>Workflow</h3>
+ </div>
+ </div>
+ </div>
+ <p> A workflow is just a composite implementation of the <code class="classname">WorkflowComponent</code> interface.
+ The <code class="methodname">invoke</code> and <code class="methodname">checkConfiguration</code> methods delegate to
+ the contained workflow components. </p>
+ <p>The Workflow class declares an <code class="methodname">adder()</code> method</p>
+ <pre class="programlisting">public void addComponent(WorkflowComponent comp)&lt;/para&gt;</pre>
+ <p> which is used by the workflow factory in order to wire up a workflow (see next section 'Workflow Configuration'). </p>
+ </div>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h3 class="title"><a name="workflow_reference_components_with_IDs"></a>Workflow Components with IDs</h3>
+ </div>
+ </div>
+ </div>
+ <p> 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 <code class="classname">WorkflowComponentWithID</code> and the <code class="methodname">setID()</code> and <code class="methodname">getID()</code> operations. Alternatively, you can also extend the base
+ class <code class="classname">AbstractWorkflowComponent</code>, which handles the ID setter/getter for you. </p>
+ </div>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h3 class="title"><a name="workflow_reference_convenience"></a>More convenience</h3>
+ </div>
+ </div>
+ </div>
+ <p> <code class="classname">AbstractWorkflowComponent</code> has a property
+ called <span class="property">skipOnErrors</span>. If set to <code class="literal">true</code>, it will not
+ execute if the workflow's 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 <code class="methodname">invoke(...)</code>, subclasses of <code class="classname">AbstractWorkflowComponent</code> have to implement <code class="methodname">invokeInternal(...)</code>. This is
+ necessary to allow the framework to intercept the invocation and stop it
+ when there are errors in the workflow. </p>
+ </div>
+ </div>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h2 class="title" style="clear: both"><a name="workflow_reference_workflow_configuration"></a>Workflow Configuration</h2>
+ </div>
+ </div>
+ </div>
+ <p> A workflow is wired up using an XML configuration language based on the dependency
+ injection pattern (DI). Here is an example (not working, just an example!): </p>
+ <pre class="programlisting">&lt;workflow&gt;
+ &lt;property name='genPath' value='/home/user/target'/&gt;
+ &lt;property name='model' value='/home/user/model.xmi'/&gt;
+ &lt;component class='an.handwriten.XmiReader'&gt;
+ &lt;model value='${model}'/&gt;
+ &lt;/component&gt;
+ &lt;component class='oaw.xpand2.Generator'&gt;
+ &lt;outlet&gt;
+ &lt;path value='${genPath}'/&gt;
+ &lt;/outlet&gt;
+ &lt;/component&gt;
+&lt;/workflow&gt;</pre>
+ <p> The root element is named <span class="emphasis"><em>workflow</em></span>, then there are some property declarations followed
+ by the declaration of two components. </p>
+ <p>Here is a tree representation of the resulting Java object graph:</p>
+ <p> </p>
+ <div class="figure"><a name="workflow_reference_java_object_graph"></a>
+ <p class="title"><b>Figure&nbsp;42.&nbsp;Java Object Graph</b></p>
+ <div class="figure-contents">
+ <div class="mediaobject"><img src="../images/java_object_graph.GIF" alt="Java Object Graph"></div>
+ </div>
+ </div>
+ <p><br class="figure-break">
+ The configuration language expresses four different concepts: </p>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h3 class="title"><a name="workflow_reference_properties"></a>Properties</h3>
+ </div>
+ </div>
+ </div>
+ <p> Borrowing from Apache Ant, we use the concept of properties. Properties can be
+ declared anywhere in a workflow file. They will be available after declaration. </p>
+ <p>We have two different kinds of properties</p>
+ <div class="orderedlist">
+ <ol type="1">
+ <li>
+ <p>simple properties</p>
+ </li>
+ <li>
+ <p>property files</p>
+ </li>
+ </ol>
+ </div>
+ <p>Here is an example:</p>
+ <pre class="programlisting">&lt;workflow&gt;
+ &lt;property name='baseDir' value='./'/&gt;
+ &lt;property file='${baseDir}/my.properties'/&gt;
+ &lt;component
+ class='my.Comp'
+ srcDir='${baseDir}'
+ modelName='${model}'
+ pathToModel='${pathToModel}'/&gt;
+&lt;/workflow&gt;</pre>
+ <p> First there is a simple property <span class="property">baseDir</span> with the value "." defined. This property
+ can be used in any attributes in the workflow file. The second property statement imports a property
+ file. Property files use the well-known Java properties file syntax. There is one feature we added:
+ You can use previously declared properties inside the properties file. </p>
+ <p>Example:</p>
+ <pre class="programlisting">model = myModel
+pathToModel = ${baseDir}/${model}.xmi</pre>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h4 class="title"><a name="workflow_reference_components"></a>Components</h4>
+ </div>
+ </div>
+ </div>
+ <p> The wired up object graph consists of so called components (A workflow component
+ is a special kind of a component). A component is declared by an XML element.
+ The name represents the property of the parent component holding this component. </p>
+ <p>Example:</p>
+ <pre class="programlisting">&lt;component class='MyBean'&gt;
+ &lt;bean class='MyBean'/&gt;
+&lt;/component&gt;</pre>
+ <p> The Java class MyBean needs to have a corresponding property accessor. E.g.: </p>
+ <pre class="programlisting">public class MyBean {
+ ...
+ public void setBean(MyBean b) {
+ bean = b;
+ }
+ ...
+}</pre>
+ <p> There are currently the following possibilities for declaring the property
+ accessors: </p>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h5 class="title"><a name="workflow_reference_accessors"></a>Accessor methods</h5>
+ </div>
+ </div>
+ </div>
+ <p> As we have seen, one possibility for declaring a dependency is to declare a
+ corresponding setter Method. </p>
+ <pre class="programlisting">public void set&lt;propertyname&gt;(&lt;PropertyType&gt;; e)</pre>
+ <p> If you want to set multiple multiple values for the same property, you
+ should define an adder method. </p>
+ <pre class="programlisting">public void add&lt;propertyname&gt;(&lt;PropertyType&gt; e)</pre>
+ <p> In some cases you may want to have key value pairs specified. This is done
+ by providing the following method: </p>
+ <pre class="programlisting">public void put(Object k,Object v)</pre>
+ </div>
+ </div>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h4 class="title"><a name="workflow_reference_component_creation"></a>Component creation</h4>
+ </div>
+ </div>
+ </div>
+ <p> The corresponding Java class (specified using the class attribute) needs
+ to have a default constructor declared. If the class attribute is
+ omitted, the Java class determined from the accessor method will be
+ used. For the preceding example we could write... </p>
+ <pre class="programlisting">&lt;component class='MyBean'&gt;
+ &lt;bean/&gt;
+&lt;/component&gt;</pre>
+ <p> ...because the setter method uses the MyBean type as its parameter type.
+ This is especially useful for more complex configurations of workflow
+ components. </p>
+ <p>Note that we will probably add factory support in the future.</p>
+ </div>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h4 class="title"><a name="workflow_reference_references"></a>References</h4>
+ </div>
+ </div>
+ </div>
+ <p> A component can have an attribute id. If this is the case we can
+ refer to this component throughout the following workflow
+ configuration. </p>
+ <p>Example:</p>
+ <pre class="programlisting">&lt;workflow&gt;
+ &lt;component class='my.Checker'&gt;
+ &lt;metaModel id='mm' class='my.MetaModel'
+ metaModelPackage='org.eclipse.metamodel'/&gt;
+ &lt;/component&gt;
+ &lt;component class='my.Generator'&gt;
+ &lt;metaModel idRef='mm'/&gt;
+ &lt;/component&gt;
+ ...
+&lt;/workflow&gt;</pre>
+ <p> In this example an object with the <span class="property">id</span> <span class="emphasis"><em>mm</em></span> (an instance of <span class="emphasis"><em>my.MetaModel</em></span>), is first declared and then referenced using the
+ attribute <span class="property">idRef</span>. Note that this object will only be instantiated
+ once and then reused. It is not allowed to specify any other
+ attributes besides <span class="property">idRef</span> for object references. </p>
+ </div>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h4 class="title"><a name="workflow_reference_simple_parameters"></a>Simple Parameters</h4>
+ </div>
+ </div>
+ </div>
+ <p> Elements with only one attribute value are simple parameters.
+ Simple parameters may not have any child elements. </p>
+ <p>Example:</p>
+ <pre class="programlisting">&lt;workflow&gt;
+ &lt;component class='my.Checker' myParam='foo'&gt;
+ &lt;anotherParam value='bar'/&gt;
+ &lt;/component&gt;</pre>
+ <p> As you can see, there are two ways to specify a simple paramter. </p>
+ <div class="orderedlist">
+ <ol type="1">
+ <li>
+ <p>using an XML attribute</p>
+ </li>
+ <li>
+ <p> using a nested XML element with an attribute value </p>
+ </li>
+ </ol>
+ </div>
+ <p> Both methods are equivalent, although declaring an attribute way
+ saves a few keystrokes. However, the attributes class, id and
+ file are reserved so they cannot be used. </p>
+ <p> Parameters are injected unsing the same accessor methods as
+ described for components. The only difference is that they are
+ not instantiated using a default constructor but instead using a
+ so called converter. </p>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h5 class="title"><a name="workflow_reference_converters"></a>Converters</h5>
+ </div>
+ </div>
+ </div>
+ <p> There are currently converter implementations registered for
+ the following Java types: </p>
+ <div class="orderedlist">
+ <ol type="1">
+ <li>
+ <p>Object</p>
+ </li>
+ <li>
+ <p>String</p>
+ </li>
+ <li>
+ <p>String[] (uses s.split(','))</p>
+ </li>
+ <li>
+ <p>Boolean (both primitive and wrapper)</p>
+ </li>
+ <li>
+ <p>Integer (both primitive and wrapper)</p>
+ </li>
+ </ol>
+ </div>
+ </div>
+ </div>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h4 class="title"><a name="workflow_reference_including_other_workflows"></a> Including other workflow files (a.k.a cartridges) </h4>
+ </div>
+ </div>
+ </div>
+ <p> If an element has a property <span class="property">file</span> it is handled as an inclusion. Using an
+ inclusion one can inject a graph described in another workflow file. Here is an example: </p>
+ <p>file 1: mybean.mwe</p>
+ <pre class="programlisting">&lt;anyname class='MyClass'/&gt;</pre>
+ <p>file 2: workflow.mwe</p>
+ <pre class="programlisting">&lt;comp class='MyBean'&gt;
+ &lt;bean file='mybean.mwe'/&gt;
+&lt;/comp&gt;</pre>
+ <p> One can pass properties and components into the included file in the usual way. </p>
+ <p>file 1: mybean.mwe</p>
+ <pre class="programlisting">&lt;anyname class='MyClass' aProp='${myParam}'&gt;
+ &lt;bean idRef='myComponent'/&gt;
+&lt;/anyname&gt;</pre>
+ <p>file 2: workflow.mwe</p>
+ <pre class="programlisting">&lt;comp class='MyBean'&gt;
+ &lt;bean file='mybean.mwe'&gt;
+ &lt;myParam value='foo'/&gt;
+ &lt;myComponent class='MyBean'/&gt;
+ &lt;/bean&gt;
+&lt;/comp&gt;</pre>
+ <p> As you can see simple parameters are mapped to properties in the included workflow file and
+ components can be accessed using the <span class="property">idRef</span> attribute. </p>
+ <p> Properties defined in the included workflow description will be overwritten by the passed properties. </p>
+ <p> The root element of a workflow description can have any name, because there is no parent defining an
+ accessor method. Additionally you have to specify the attribute class for a root element. There is
+ only one exception: If the root element is named workflow the engine knows that it has to
+ instantiate the type <code class="classname">org.eclipse.emf.mwe.internal.core.Workflow</code>. Of course you can
+ specify your own subtype of <code class="classname">org.eclipse.emf.mwe.internal.core.Workflow</code> using the <span class="property">class</span> attribute (if you need to for any reason). </p>
+ </div>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h4 class="title"><a name="workflow_reference_inheritall"></a>InheritAll Feature</h4>
+ </div>
+ </div>
+ </div>
+ <p> If you don't want to explicitely pass the parameters to an included workflow description, you can
+ use the <span class="property">inheritAll</span> attribute. This will make all the properties and beans that
+ are visible to the actual workflow file also visible to the included workflow file. </p>
+ <pre class="programlisting">&lt;component file="my/included/workflow.mwe" inheritAll="true"/&gt;</pre>
+ </div>
+ </div>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h3 class="title"><a name="workflow_reference_component_implementation"></a>Component Implementation and Workflow Execution</h3>
+ </div>
+ </div>
+ </div>
+ <p> This section describes how to implement workflow components, how they can communicate
+ with each other and how the workflow execution can be controlled. </p>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h4 class="title"><a name="workflow_reference_context"></a>The Workflow Context</h4>
+ </div>
+ </div>
+ </div>
+ <p> Workflow components have to communicate among each other. For example, if an
+ XMIReader component reads a model that a constraint checker component wants to
+ check, the model must be passed from the reader to the checker. The way this happens
+ is as follows. In the invoke operation, a workflow component has access to the
+ so-called workflow context. This context contains any number of named slots. In
+ order to communicate, two components agree on a slot name, the first component puts
+ an object into that slot and the second component takes it from there. Basically,
+ slots are named variables global to the workflow. The slot names are configured from
+ the workflow file. Here is an example: </p>
+ <pre class="programlisting">&lt;?xml version="1.0" encoding="windows-1252"?&gt;
+&lt;workflow&gt;
+ &lt;property file="workflow.properties"/&gt;
+
+ &lt;component id="xmiParser"
+ class="my.XmiReader"&gt;
+ &lt;outputSlot value="model"/&gt;
+ &lt;/component&gt;
+
+ &lt;component id="checker" class="datamodel.generator.Checker"&gt;
+ &lt;modelSlot value="model"/&gt;
+ &lt;/component&gt;
+&lt;/workflow&gt;</pre>
+ <p> As you can see, both these workflow components use the slot named <span class="emphasis"><em>model</em></span>. Below is
+ the (abbreviated) implementation of the <code class="classname">XmiReader</code>. It stores the model data
+ structure into the workflow context in the slot whose name was configured in the workflow file. </p>
+ <pre class="programlisting">public class XmiReader implements WorkflowComponent {
+
+ private String outputSlot = null;
+
+ public void setOutputSlot(String outputSlot) {
+ this.outputSlot = outputSlot;
+ }
+
+ public void invoke(WorkflowContext ctx, ProgressMonitor monitor,
+ Issues issues) {
+ Object theModel = readModel();
+ ctx.put( outputSlot, theModel );
+ }
+
+}</pre>
+ <p>The checker component reads the model from that slot:</p>
+ <pre class="programlisting">public class Checker implements WorkflowComponent {
+
+ private String modelSlot;
+
+ public final void setModelSlot( String ms ) {
+ this.modelSlot = ms;
+ }
+
+ public final void invoke(WorkflowContext ctx,
+ ProgressMonitor monitor, Issues issues) {
+
+ Object model = ctx.get(modelSlot);
+ check(model);
+ }
+}</pre>
+ </div>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h4 class="title"><a name="workflow_reference_issues"></a>Issues</h4>
+ </div>
+ </div>
+ </div>
+ <p> Issues provide a way to report errors and warnings. There are two places where issues are used in
+ component implementations: </p>
+ <div class="orderedlist">
+ <ol type="1">
+ <li>
+ <p> Inside the checkConfiguration operation, you can report errors or
+ warnings. This operation is called before the workflow starts running. </p>
+ </li>
+ <li>
+ <p> Inside the invoke operation, you can report errors or warnings that
+ occur during the execution of the workflow. Typical examples are
+ constraint violations. </p>
+ </li>
+ </ol>
+ </div>
+ <p> The Issues API is pretty straightforward: you can call addError and addWarning.
+ The operations have three parameters: the reporting component, a message as well
+ as the model element that caused the problem, if there is one. The operations
+ are also available in a two-parameter version, omitting the first (reporting
+ component) parameter. </p>
+ </div>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h4 class="title"><a name="workflow_reference_controlling_workflow"></a>Controlling the Workflow</h4>
+ </div>
+ </div>
+ </div>
+ <p> There is an implicit way of controlling the workflow: if there are errors
+ reported from any of the checkConfiguration operations of any workflow
+ component, the workflow will not start running! </p>
+ <p> There is also an explicit way of terminating the execution of the workflow:
+ if any invoke operation throws a <code class="classname">WorkflowInterruptedException</code> (a runtime
+ exception) the workflow will terminate immediately. </p>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h5 class="title"><a name="d0e2571"></a>Workflow AO</h5>
+ </div>
+ </div>
+ </div>
+ <p> It is sometimes necessary to enhance existing workflow component
+ declarations with additional properties. This is exemplified in the
+ Template AOP example. To implement such an Advice Component, you have to
+ extend the AbstractWorkflowAdvice class. You have to implement all the
+ necessary getters and setters for the properties you want to be able to
+ specify for that advice; also you have to implement the weave()
+ Operation. In this operation, which takes the advised component as a
+ parameter, you have to set the advised parameters: </p>
+ <pre class="programlisting">public class GeneratorAdvice extends AbstractWorkflowAdvice {
+
+ private String advices;
+
+ public String getAdvices() {
+ return advices;
+ }
+
+ public void setAdvices(String advices) {
+ this.advices = advices;
+ }
+
+ @Override
+ public void weave(WorkflowComponent c) {
+ Generator gen = (Generator)c;
+ gen.setAdvices(advices);
+ }
+
+}</pre>
+ <p> In the workflow file things are straight forward: You have to specify
+ the advice's component class to be the advice component, and use the
+ special property adviceTarget to identify the target component: </p>
+ <pre class="programlisting">&lt;workflow&gt;
+
+ &lt;cartridge file="workflow.mwe"/&gt;
+ &lt;component adviceTarget="generator"
+ class="oaw.xpand2.GeneratorAdvice"&gt;
+ &lt;advices value="templates::Advices"/&gt;
+ &lt;/component&gt;
+ &lt;/workflow&gt;</pre>
+ </div>
+ </div>
+ </div>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h3 class="title"><a name="workflow_reference_invoking_a_workflow"></a>Invoking a workflow</h3>
+ </div>
+ </div>
+ </div>
+ <p> If you have described your generator process in a workflow file, you might want to run
+ it :-) There are different possibilities for doing so. </p>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h4 class="title"><a name="workflow_reference_workflowrunner"></a>Starting the WorkflowRunner</h4>
+ </div>
+ </div>
+ </div>
+ <p> The class org.openarchitectureware.workflow.WorkflowRunner is the main entry point
+ if you want to run the workflow from the command line. Take a look at the following
+ example: </p>
+ <pre class="programlisting">java org.openarch..WorkflowRunner path/workflow.mwe</pre>
+ <p>You can override properties using the -p option:</p>
+ <pre class="programlisting">java org.openarch..WorkflowRunner -pbasedir=/base/ path/workflow.mwe</pre>
+ </div>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h4 class="title"><a name="workflow_reference_starting_with_ant"></a>Starting with Ant</h4>
+ </div>
+ </div>
+ </div>
+ <p>We also have an Ant task. Here's an example:</p>
+ <pre class="programlisting"> &lt;target name='generate'&gt;
+ &lt;taskdef name="workflow" classname="org.eclipse.emf.mwe.core.ant.WorkflowAntTask"/&gt;
+ &lt;workflow file='path/workflow.mwe'&gt;
+ &lt;param name='baseDir' value='/base/'/&gt;
+ &lt;/workflow&gt;
+ ...
+ &lt;/target&gt;</pre>
+ <p> The Workflow ant task extends the Java ant task. Therefore, you have all the
+ properties known from that task (classpath, etc.). </p>
+ </div>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h4 class="title"><a name="workflow_reference_starting_from_your_own_code"></a>Starting from you own code</h4>
+ </div>
+ </div>
+ </div>
+ <p> You can also run the generator from your own application code. Two things to note: </p>
+ <div class="orderedlist">
+ <ol type="1">
+ <li>
+ <p> the contents of the properties map override the properties defined
+ in the workflow. </p>
+ </li>
+ <li>
+ <p> The slotContents map allows you to fill stuff into the workflow from
+ your application. This is a typical use case: you run MWE from
+ within your app because you already have a model in memory. </p>
+ </li>
+ </ol>
+ </div>
+ <pre class="programlisting"> String wfFile = "somePath\\workflow.mwe";
+ Map properties = new HashMap();
+ Map slotContents = new HashMap();
+ new WorkflowRunner().run(wfFile ,
+ new NullProgressMonitor(), properties, slotContents)</pre>
+ </div>
+ <div class="section" lang="en">
+ <div class="titlepage">
+ <div>
+ <div>
+ <h4 class="title"><a name="d0e2621"></a>Starting from Eclipse</h4>
+ </div>
+ </div>
+ </div>
+ <p> You can also run a workflow file from within Eclipse, if you have
+ installed the MWE plugins. Just right-click on the workflow file
+ (whatever.mwe) and select <span class="guimenu">Run As</span> &#8594; <span class="guimenuitem">MWE Workflow</span>.</p>
+ </div>
+ </div>
+ </div>
+</div>
+</body>
+</html>