|
| Re: Serialization of QVT-O Traces [message #1736816 is a reply to message #1736735] |
Sat, 02 July 2016 08:32   |
 Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
You report that the XMI is fine, but the baseURI is unsatisfactory. This
is almost certainly due to inadequate initilaization, which is difficult
to comment on without an executable repro and is probably attributable
to code that you have not shared with us. See
https://wiki.eclipse.org/OCL/ForumNetiquette for some suggestions on how
to communicate more effectively.
Be aware that the Eclipse QVTo incremental execution is an experimental
facility that can only work in favourable situations. You should only
use it if you are confident that your needs for re-execution fall within
the limited capablities. In particular, because it does not trace what
was not done, it cannot re-execute where a guard condition changes from
false to true, or where additional objects are involved. These
limitations are not bugs, they are fundamental and explained by QVT 1.3:
/QVT 1.3 8.1.11.8 Persisted Trace Data//
//The trace-data may be persisted and reloaded to support a
re-execution. However the trace-record does not trace//
//configuration data, transformation properties or intermediate data,
and does not involve a deep clone of every traced//
//object. It is therefore not possible to use a persisted form of the
trace-data to support incremental re-execution of an//
//arbitrary QVTo transformation since the required object state may not
be present in persisted trace. A well-behaved//
//transformation that avoids dependence on mutable object properties or
other untraced facilities may be re-executable./
The Eclipse QVTd support has the foundations for rigorous incremental
execution and should support incremental QVTc and/or QVTr in Oxygen.
Regards
Ed Willink
On 01/07/2016 12:45, Stephan Seifermann wrote:
> Dear all,
>
> I try to execute a QVT-O transformation incrementally. In order to do
> this, I want to store the traces generated during the execution to
> reuse them in a later transformation. My approach is as
> follows:ExecutionContextImpl context = new ExecutionContextImpl();
> context.getSessionData().setValue(QVTEvaluationOptions.INCREMENTAL_UPDATE_TRACE,
> transformationTrace);
> TransformationExecutor executor = new
> TransformationExecutor(transformationURI);
> ExecutionDiagnostic result = executor.execute(context,
> transformationParameters);
>
> Resource traceResource = resourceSet.createResource(traceURI);
> traceResource.getContents().addAll(traceModel.getTraceContent());
> traceResource.save(Collections.emptyMap());
>
> The serialized XMI file looks fine (just like the one produced when
> executing the transformation via the UI). The problem arises when I
> try to load the trace from a newly generated ResourceSet:
> Resource traceResource = resourceSet.getResource(traceURI, false);
> Trace traceModel = new
> Trace(traceResource.getContents());java.lang.IllegalArgumentException:
> resolve against non-hierarchical or relative base
> at
> org.eclipse.emf.common.util.URI$Hierarchical.resolve(URI.java:3516)
> at org.eclipse.emf.common.util.URI.resolve(URI.java:5547)
> at
> org.eclipse.m2m.internal.qvt.oml.compiler.URIUnitResolver.doResolveUnit(URIUnitResolver.java:111)
> at
> org.eclipse.m2m.internal.qvt.oml.compiler.URIUnitResolver.doResolveUnit(URIUnitResolver.java:93)
> at
> org.eclipse.m2m.internal.qvt.oml.compiler.DelegatingUnitResolver.resolveUnit(DelegatingUnitResolver.java:45)
> at
> org.eclipse.m2m.internal.qvt.oml.compiler.DelegatingUnitResolver.resolveUnit(DelegatingUnitResolver.java:37)
> at
> org.eclipse.m2m.internal.qvt.oml.compiler.UnitResolverFactory.findUnit(UnitResolverFactory.java:39)
> at
> org.eclipse.m2m.internal.qvt.oml.compiler.UnitResolverFactory.access$0(UnitResolverFactory.java:37)
> at
> org.eclipse.m2m.internal.qvt.oml.compiler.UnitResolverFactory$Registry$BasicRegistry.getUnit(UnitResolverFactory.java:117)
> at
> org.eclipse.m2m.internal.qvt.oml.blackbox.java.BlackboxResourceFactory$1.load(BlackboxResourceFactory.java:46)
> at
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoad(ResourceSetImpl.java:259)
> at
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:274)
> at
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:406)
> at
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObject(ResourceSetImpl.java:220)
> ..
> The reason for the exception is the creation of a URI without a proper
> scheme. Therefore, it can never be a valid base URI to be used in a
> resolution process:
> baseURI = URI.createURI("/");
> The URL to be resolved is the reference to the mapping
> operation:<mappingOperation name="diagramToDiagram"
> package="PapyrusClass2Text" module="PapyrusClass2Text">
> <runtimeMappingOperation href="qvto:/module.env#//diagramToDiagram"/>
> </mappingOperation>
>
> I got two questions: Do I handle the trace model writing/reading
> correctly and the wrongly created base URI is a bug?
> Do I have to load the module into the resource set in order to get a
> valid trace model for the QVT-O transformation engine or will there be
> proxies that are resolved correctly during the transformation?
> Best regards
> Stephan
>
>
|
|
|
|
Powered by
FUDForum. Page generated in 0.03033 seconds
] 
Search
Help
Register
Login
Home
