| Xtext 1.x->2x: relative vs. absolute XMI references in ecore file [message #847777] |
Tue, 17 April 2012 12:35  |
Eclipse User |
|
|
|
Hi,
I'm currently migrating a project from Xtext 1.x to 2.x. The grammar has
not been changed, however the generated ecore file (the file, not the
model) is different now.
E.g., for a given grammar element
Def: (imports+=Import)*
Xtext 1.x generates an ecore model which is serialized such as:
<ecore:EPackage xmi:version="2.0" ...>
<eClassifiers xsi:type="ecore:EClass" name="Def">
<eStructuralFeatures xsi:type="ecore:EReference" name="imports"
upperBound="-1"
eType="#//Import" containment="true"/>
...
The Xtext 2.x generated version looks like that:
<ecore:EPackage xmi:version="2.0" ...>
<eClassifiers xsi:type="ecore:EClass" name="Def">
<eStructuralFeatures xsi:type="ecore:EReference" name="imports"
upperBound="-1"
eType="ecore:EClass
platform:/resource/my.project.name/src-gen/de/feu/ps/mylang/dsl/Mylang.ecore#//Import"
containment="true"/>
Although the model is similar, the xmi file has changed: Instead of
using relative references, absolute XPath expressions are used. This
causes problems when copying/moving the file to other locations or when
using it outside Eclipse.
The problem can be manually fixed by simply opening the ecore file with
the Sample Ecore Editor, changing something and saving it. The saved
version is then using relative XPath expressions again.
Is there a way of telling the Xtext generator to use relative XPath
expression in the fist place?
Cheers,
Jens
BTW: I'm wondering to post this behavior as a bug. Is it a bug? Or is it
a feature?
|
|
|
|
|
|
|
| Re: Xtext 1.x-&gt;2x: relative vs. absolute XMI references in ecore file [message #848499 is a reply to message #848478] |
Wed, 18 April 2012 05:30  |
| Eclipse User |
|
|
|
Hi
The observed change is because EMF, by default, generates relative
references when possible and only absolute references when necessary.
The actual change is that the precondition for relative references is
differently satisfied because in one case EMF did not consider the
target URI to be relatively reachable, which depends on the quality of
platform: URI mappings.
Xtext or rather MWE2's StandaloneSetup tries to be helpful by analysing
the classpath for plausible models and populating platform:/resource
accordingly. Unfortunately the corresponding support for
platform:/plugin is missing.
So the actual change may be caused by the projects that you have open or
even just deeply available to MWE2's scan, or may be caused by an
evolution in the empathy of the model finding algorithms.
Regards
Ed Willink
On 18/04/2012 10:02, Jens v.P. wrote:
> On 17.04.12 20:25, Christian Dietrich wrote:
>> Btw i cannot reproduce this problem using Xtext 2.2.
>
> I'm using Xtext 2.0.1 (Eclipse 3.7 SR2 Modeling). I have now tested
> the workflow with 2.3 (Eclipse 4.2 M6), and it generates relative
> XMI-XPaths references. It seems as if this problem has been fixed
> after 2.0.1.
>
> I will try to skip 2.0.1 and directly use 2.3 (and Eclipse 4.2).
>
> Anyway, it would be interesting to know how to fix this problem in 2.0.1.
>
>> can you share your workflow?
> See below.
>
> Cheers,
> Jens
>
>
> module de.feu.ps.refacola.dsl.Refacola
>
> import org.eclipse.emf.mwe.utils.*
> import org.eclipse.xtext.generator.*
> import org.eclipse.xtext.ui.generator.*
>
> var grammarURI = "classpath:/de/feu/ps/refacola/dsl/Refacola.xtext"
> var file.extensions = "refacola"
> var projectName = "de.feu.ps.refacola.dsl"
> var runtimeProject = "../${projectName}"
>
> Workflow {
> bean = StandaloneSetup {
> platformUri = "${runtimeProject}/.."
> }
> component = DirectoryCleaner {
> directory = "${runtimeProject}/src-gen"
> }
> component = DirectoryCleaner {
> directory = "${runtimeProject}.ui/src-gen"
> }
> component = Generator {
> pathRtProject = runtimeProject
> pathUiProject = "${runtimeProject}.ui"
> projectNameRt = projectName
> projectNameUi = "${projectName}.ui"
> language = {
> uri = grammarURI
> fileExtensions = file.extensions
>
> fragment = grammarAccess.GrammarAccessFragment {}
> fragment = ecore.EcoreGeneratorFragment {}
> fragment = parseTreeConstructor.ParseTreeConstructorFragment {}
> fragment = resourceFactory.ResourceFactoryFragment {
> fileExtensions = file.extensions
> }
>
> fragment = parser.antlr.XtextAntlrGeneratorFragment {
> }
>
> fragment = validation.JavaValidatorFragment {
> composedCheck = "org.eclipse.xtext.validation.ImportUriValidator"
> composedCheck =
> "org.eclipse.xtext.validation.NamesAreUniqueValidator"
> }
>
> fragment = scoping.RefacolaScopingFragment {}
> fragment = exporting.QualifiedNamesFragment {}
> fragment = builder.BuilderIntegrationFragment {}
> fragment = formatting.FormatterFragment {}
> fragment = labeling.LabelProviderFragment {}
>
> // Xtext 1.x
> // fragment = outline.TransformerFragment {}
> // fragment = outline.OutlineNodeAdapterFactoryFragment {}
> // Xtext 2.x:
> fragment = outline.OutlineTreeProviderFragment {}
> // -------
> fragment = outline.QuickOutlineFragment {}
> fragment = quickfix.QuickfixProviderFragment {}
> fragment = contentAssist.JavaBasedContentAssistFragment {}
> fragment = parser.antlr.XtextAntlrUiGeneratorFragment {}
> }
> }
> }
>
|
|
|
Powered by
FUDForum. Page generated in 0.07974 seconds
Home