| Xtext 1.x->2x: relative vs. absolute XMI references in ecore file [message #847777] |
Tue, 17 April 2012 16:35  |
|
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 #848413 is a reply to message #847859] |
Wed, 18 April 2012 07:41  |
|
On 17.04.12 20:22, Christian Dietrich wrote:
> why do you care?
Besides editing the DSL specific models manually using the Xtext editor,
some models are created as target models of a model-to-model (m2m)
transformation. The generated ecore model is required by the m2m
transformation, as it is the metamodel of the target model. Since the
m2m transformation is running in a different environment (a different
Eclipse installation and/or standalone w/o any "platform"), the ecore
model must not rely on absolute paths.
Cheers,
Jens
|
|
|
| Re: Xtext 1.x-&gt;2x: relative vs. absolute XMI references in ecore file [message #848478 is a reply to message #847863] |
Wed, 18 April 2012 09:02 |
|
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 {}
}
}
}
|
|
|
| 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 09:30 |
 Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
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.03723 seconds
] 
Search
Help
Register
Login
Home
