Invocation API should support trace generation

[eclipse-qvt-oml-bot]

| --- | --- | | Bugzilla Link | 282645 | | Status | NEW | | Importance | P3 normal | | Reported | Jul 07, 2009 06:06 EDT | | Modified | Nov 16, 2011 14:08 EDT | | Version | 2.0 | | Reporter | Radomil Dvorak |

Description

The transformation executor does not provide any way to expose the traces from transformation execution. \ Though, the trace meta-model is still internal to QVTo, we might persist the trace model at a given URI or in a resource assigned to the execution environment.

[eclipse-qvt-oml-bot]

By Max Bureck on Jul 15, 2010 07:21

What is the target version of a fix for this Bug? It seems that there is no possibility for trace generation in the current API (version 3.0), or did I miss something?

[eclipse-qvt-oml-bot]

By mm on Jul 27, 2010 08:24

How to enable the trace file generation when invoking a qvto transformation from a java code as it is done in the following link:

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.m2m/org.eclipse.m2m.qvt.oml/examples/org.eclipse.m2m.qvt.oml.econ2009.tutorial/projects/qvto.ecore2uml.invoke/src/qvto/ecore2uml/invoke/ConvertEcore2UML.java?root=Modeling_Project&view=markup

[eclipse-qvt-oml-bot]

By Ed Willink on Jul 30, 2010 09:11

The request should really be to make the Trace Meta-Model public API.

---

So long as the Trace Meta-Model is internal, there is not much point having a public API to access internal API, so the following is a perfectly reasonable approach for those determined to use Internal API.

@SuppressWarnings("restriction") ....\ final Resource traceResource = new ResourceImpl();\ InternalTransformationExecutor txExecutor = new InternalTransformationExecutor(txURI, registry)\ {\ @Override\ protected void handleExecutionTraces(Trace traces) {\ traceResource.getContents().add(traces);\ super.handleExecutionTraces(traces);\ } \ };\ ExecutionDiagnostic executionDiagnostic =\ txExecutor.execute(executionContext, inputModelParameters, outputModelParameters);

[eclipse-qvt-oml-bot]

By Nicolas Rouquette on Sep 13, 2010 02:22

I use extensively QVTo traces within QVTo and outside. \ This is useful for splitting a transformation in 2 phases:

• a QVTO phase
• a non-QVTO phase that is driven from the trace of the 1st phase transformation

For the 2nd phase transformation, I've generated a simple QVToTrace API from the XML Schemas with JAXB.

THis allows me to read a .qvtotrace file in environments where I don't have Eclipse EMF/QVTo but where the trace records provide useful information to finish a transformation where I can access other APIs that do not integrate well or at all with Eclipse.

Since there is no EMF at all, I added a simple version of org.eclipse.m2m.internal.qvt.oml.trace.ModelElement to get the href as a string:

package org.eclipse.m2m.internal.qvt.oml.trace;

import javax.xml.bind.annotation.XmlAccessType;\ import javax.xml.bind.annotation.XmlAccessorType;\ import javax.xml.bind.annotation.XmlAttribute;\ import javax.xml.bind.annotation.XmlType;

@XmlAccessorType(XmlAccessType.FIELD)\ @XmlType(name = "ModelElement", propOrder = {\ "href"\ })\ public class ModelElement {\ @XmlAttribute(name = "href")\ protected String href;\ \ public String getHRef() {\ return href;\ }\ \ public void setHRef(String href) {\ this.href = href;\ }\ }

I would prefer having a public facility to access QVTo traces; one that can work with EMF (i.e., resolving the ModelElement hrefs to EMF EObjects) and one that works without EMF (i.e., ModelElement hrefs are just strings)