GMF/xtext diagram/model creation problem [message #1106028] |
Tue, 10 September 2013 11:31  |
Eclipse User |
|
|
|
Hello,
we are currently working on some UML like gmf editors using xtext and gmf as basis. The dsl is working well but now we are facing on a problem in the diagram creation:
public static Resource createDiagram(URI diagramURI, URI modelURI,
IProgressMonitor progressMonitor) {
TransactionalEditingDomain editingDomain = GMFEditingDomainFactory.INSTANCE
.createEditingDomain();
progressMonitor
.beginTask(
christ.xtext.modelingframework.cmfdsl.cmfDsl.diagram.part.Messages.CmfDslDiagramEditorUtil_CreateDiagramProgressTask,
3);
final Resource diagramResource = editingDomain.getResourceSet()
.createResource(diagramURI);
final Resource modelResource = editingDomain.getResourceSet()
.createResource(modelURI); //THIS LINE!!!!!
The last line returns in the current project a LazyLinkingResource, in a older project it returns a XMIResourceImpl. The LazyLinkingResource results the things described in http://www.eclipse.org/forums/index.php/t/521338/. Do you have any idea how to fix it or what we did wrong or how we can force it to create a XMIResourceImpl -resource?
Thanks.
Thomas
|
|
|
Re: GMF/xtext diagram/model creation problem [message #1106718 is a reply to message #1106028] |
Wed, 11 September 2013 08:55   |
Eclipse User |
|
|
|
Xtext models must be read in a LazyLinkingResource, as it encapsulates
the parser and the serializer.
XMIResource only works for models serialized as XMI.
If your error is really the same as the described link, it is due to the
fact that you're trying to create an Xtext resource with an invalid root
element. Make sure the model conforms to the grammar, e.g. starts with
an element that could be returned by the entry rule.
Am 10.09.13 21:45, schrieb Thomas Högg:
> Hello,
>
> we are currently working on some UML like gmf editors using xtext and
> gmf as basis. The dsl is working well but now we are facing on a problem
> in the diagram creation:
>
> public static Resource createDiagram(URI diagramURI, URI modelURI,
> IProgressMonitor progressMonitor) {
> TransactionalEditingDomain editingDomain =
> GMFEditingDomainFactory.INSTANCE
> .createEditingDomain();
> progressMonitor
> .beginTask(
>
> christ.xtext.modelingframework.cmfdsl.cmfDsl.diagram.part.Messages.CmfDslDiagramEditorUtil_CreateDiagramProgressTask,
>
> 3);
>
> final Resource diagramResource = editingDomain.getResourceSet()
> .createResource(diagramURI);
> final Resource modelResource = editingDomain.getResourceSet()
> .createResource(modelURI); //THIS LINE!!!!!
>
> The last line returns in the current project a LazyLinkingResource, in a
> older project it returns a XMIResourceImpl. The LazyLinkingResource
> results the things described in
> http://www.eclipse.org/forums/index.php/t/521338/. Do you have any idea
> how to fix it or what we did wrong or how we can force it to create a
> XMIResourceImpl -resource?
>
> Thanks.
> Thomas
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
|
|
|
|
|
|
Re: GMF/xtext diagram/model creation problem [message #1111388 is a reply to message #1110994] |
Wed, 18 September 2013 02:26  |
Eclipse User |
|
|
|
The this sounds a bit like a serializer bug.
Would you file a bugzilla to ensure this is not the case?
Am 17.09.13 18:08, schrieb Thomas Högg:
> Yes, the XMI resource works well. Maybe to clarify what we want to model:
>
> The xtext file should allow to define multiple diagrams/objects what
> works very well with the first structure while for the gmf editor we
> planned that there is one diagram per file only. So we started the
> diagram creation with state-diagram as entry point. As long as we don't
> make the StateMachineDiagram placeable we have the here addressed behavior.
>
> So for the moment we solved the problem allowing it to place all the
> diagrams using a node and fill them with content. This fits to the xtext
> dsl now and works with the serializer.
>
> Thanks.
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
|
|
|
Powered by
FUDForum. Page generated in 0.04697 seconds