- * At specification time, <code>executionSpec</code> represents the spec
- * of the parameters accepted by the process, with, among others: type,
- * default value and, optionally, possible values for each parameter. Thus
- * ExecutionSpec might be a huge object. Note that when marshalling only
- * a reference to a specific ExecutionSpec is stored in the XML to
- * optimize performance and avoid redundancy between various
- * ExecutionFlowDesciptor that might have the same ExecutionSpec.
- *
- * At runtime, we build a RealizedFlow which references an
- * ExecutionFlowDescriptor. As it happens AFTER marshalling /
- * unmarshalling process, the ExecutionSpec is null but we manage to
- * retrieve the ExecutionSpec and store it in the RealizedFlow, whereas
- * set values of the parameters are stored in the <code>values</code>
- * map.
- *
- * @author bsinou
+ * At specification time, <code>executionSpec</code> represents the spec of the
+ * parameters accepted by the process, with, among others: type, default value
+ * and, optionally, possible values for each parameter. Thus ExecutionSpec might
+ * be a huge object. Note that when marshalling only a reference to a specific
+ * ExecutionSpec is stored in the XML to optimize performance and avoid
+ * redundancy between various ExecutionFlowDesciptor that might have the same
+ * ExecutionSpec.