Home » Modeling » TMF (Xtext) » Problems with imports after migrating to xtext 2.0
| Problems with imports after migrating to xtext 2.0 [message #719398] |
Fri, 26 August 2011 18:24  |
Eclipse User |
|
|
|
Hi anybody,
In my szenario I have different grammars, which refer to different file-suffixes:
.wf: workflow-files
.mask: mask-files
I have some crossreferences between these files,
e.g:
in a file vsa.marvin.mod.schulung.workflow.CustomerManagement.wf:
workflow-language-v2.0 package vsa.marvin.mod.schulung.^workflow;
import vsa.marvin.mod.schulung.^workflow.OverviewMask;
.....
javaMask OverviewMask
I can't resolve these crossreferences anymore.
I debugged and came to the following problem:
In ImportScope.getLocalElementsByName(QualifiedName name) there is a call:
importFrom.getExportedObjects(type, resolvedName,isIgnoreCase()
This tries to get all exported objects of the parentpackage, I guess, again calling ImportScope.getLocalElementsByName(QFN). This time there is only one normalizer in the list (vsa.marvin.mod.schulung.workflow.CustomerManagement.*). It tries to resolve the OverviewMask-Import by append the relativeName (in this case vsa.marvin.mod.schulung.workflow.OverviewMask), leading to an resolved name "vsa.marvin.mod.schulung.workflow.CustomerManagement.vsa.marvin.mod.schulung.workflow.OverviewMask", which is wrong and doesn't find any elements.
How do I get a importoptimizer that resolves vsa.marvin.mod.schulung.workflow.OverviewMask in a correct way?
Would be nice, if you could help me.
Best regards
Markus
See the stack:
Thread [Worker-36] (Suspended)
owns: vsa.marvin.mod.common.resource.DelegatingXtextResource (id=141)
org.eclipse.xtext.scoping.impl.ImportNormalizer.resolve(org.eclipse.xtext.naming.QualifiedName) line: 59
org.eclipse.xtext.scoping.impl.ImportScope.getLocalElementsByName(org.eclipse.xtext.naming.QualifiedName) line: 150
org.eclipse.xtext.scoping.impl.ImportScope(org.eclipse.xtext.scoping.impl.AbstractScope).getElements(org.eclipse.xtext.naming.QualifiedName) line: 127
org.eclipse.xtext.scoping.impl.ScopeBasedSelectable.getExportedObjects(org.eclipse.emf.ecore.EClass, org.eclipse.xtext.naming.QualifiedName, boolean) line: 37
org.eclipse.xtext.scoping.impl.ImportScope.getLocalElementsByName(org.eclipse.xtext.naming.QualifiedName) line: 152
org.eclipse.xtext.scoping.impl.ImportScope.getSingleLocalElementByName(org.eclipse.xtext.naming.QualifiedName) line: 140
org.eclipse.xtext.scoping.impl.ImportScope(org.eclipse.xtext.scoping.impl.AbstractScope).getSingleElement(org.eclipse.xtext.naming.QualifiedName) line: 101
org.eclipse.xtext.scoping.impl.ImportScope(org.eclipse.xtext.scoping.impl.AbstractScope).getSingleElement(org.eclipse.xtext.naming.QualifiedName) line: 104
org.eclipse.xtext.scoping.impl.ImportScope(org.eclipse.xtext.scoping.impl.AbstractScope).getSingleElement(org.eclipse.xtext.naming.QualifiedName) line: 104
vsa.marvin.mod.common.services.MarvinLinkingService.getLinkedObjects(org.eclipse.emf.ecore.EObject, org.eclipse.emf.ecore.EReference, org.eclipse.xtext.nodemodel.INode) line: 101
vsa.marvin.mod.common.resource.DelegatingXtextResource(org.eclipse.xtext.linking.lazy.LazyLinkingResource).getEObject(java.lang.String) line: 169
vsa.marvin.mod.common.resource.DelegatingXtextResource.getEObject(java.lang.String) line: 85
vsa.marvin.mod.common.resource.DelegatingXtextResource(org.eclipse.xtext.linking.lazy.LazyLinkingResource).resolveLazyCrossReference(org.eclipse.emf.ecore.InternalEObject, org.eclipse.emf.ecore.EStructuralFeature) line: 138
vsa.marvin.mod.common.resource.DelegatingXtextResource(org.eclipse.xtext.linking.lazy.LazyLinkingResource).resolveLazyCrossReferences(org.eclipse.xtext.util.CancelIndicator) line: 102
org.eclipse.xtext.EcoreUtil2.resolveLazyCrossReferences(org.eclipse.emf.ecore.resource.Resource, org.eclipse.xtext.util.CancelIndicator) line: 417
org.eclipse.xtext.validation.ResourceValidatorImpl.resolveProxies(org.eclipse.emf.ecore.resource.Resource, org.eclipse.xtext.util.CancelIndicator) line: 127
org.eclipse.xtext.validation.ResourceValidatorImpl.validate(org.eclipse.emf.ecore.resource.Resource, org.eclipse.xtext.validation.CheckMode, org.eclipse.xtext.util.CancelIndicator) line: 62
org.eclipse.xtext.ui.editor.validation.ValidationJob$1.exec(org.eclipse.xtext.resource.XtextResource) line: 79
org.eclipse.xtext.ui.editor.validation.ValidationJob$1.exec(java.lang.Object) line: 1
org.eclipse.xtext.ui.editor.model.XtextDocument$XtextDocumentLocker(org.eclipse.xtext.util.concurrent.AbstractReadWriteAcces<P>).readOnly(org.eclipse.xtext.util.concurrent.IUnitOfWork<T,P>) line: 32
org.eclipse.xtext.ui.editor.model.XtextDocument.readOnly(org.eclipse.xtext.util.concurrent.IUnitOfWork<T,org.eclipse.xtext.resource.XtextResource>) line: 86
org.eclipse.xtext.ui.editor.validation.ValidationJob.createIssues(org.eclipse.core.runtime.IProgressMonitor) line: 75
org.eclipse.xtext.ui.editor.validation.ValidationJob.run(org.eclipse.core.runtime.IProgressMonitor) line: 64
org.eclipse.core.internal.jobs.Worker.run() line: 54
|
|
| |
| Re: Problems with imports after migrating to xtext 2.0 [message #719459 is a reply to message #719398] |
Sat, 27 August 2011 05:48  |
| Eclipse User |
|
|
|
Hi Markus,
there are by default a number of import scopes nested into each other.
If one cannot find something meaningful in its parent package, it will
simply delegate with the plain name to it (see
AbstractScope#getElements(QN)).
The unresolved references are probably not caused by the behavior that
you observed in the debugger.
Regards,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
On 27.08.11 00:24, Markus Oley wrote:
> Hi anybody,
> In my szenario I have different grammars, which refer to different
> file-suffixes:
> wf: workflow-files
> mask: mask-files
>
> I have some crossreferences between these files, e.g:
> in a file vsa.marvin.mod.schulung.workflow.CustomerManagement.wf:
> workflow-language-v2.0 package vsa.marvin.mod.schulung.^workflow;
>
> import vsa.marvin.mod.schulung.^workflow.OverviewMask;
>
> ....
>
> javaMask OverviewMask
>
>
> I can't resolve these crossreferences anymore. I debugged and came to
> the following problem:
> In ImportScope.getLocalElementsByName(QualifiedName name) there is a
> call: importFrom.getExportedObjects(type, resolvedName,isIgnoreCase()
> This tries to get all exported objects of the parentpackage, I guess,
> again calling ImportScope.getLocalElementsByName(QFN). This time there
> is only one normalizer in the list
> (vsa.marvin.mod.schulung.workflow.CustomerManagement.*). It tries to
> resolve the OverviewMask-Import by append the relativeName (in this case
> vsa.marvin.mod.schulung.workflow.OverviewMask), leading to an resolved
> name
> "vsa.marvin.mod.schulung.workflow.CustomerManagement.vsa.marvin.mod.schulung.workflow.OverviewMask",
> which is wrong and doesn't find any elements.
>
> How do I get a importoptimizer that resolves
> vsa.marvin.mod.schulung.workflow.OverviewMask in a correct way?
> Would be nice, if you could help me.
>
> Best regards Markus
>
>
>
> See the stack: Thread [Worker-36] (Suspended)
> owns: vsa.marvin.mod.common.resource.DelegatingXtextResource (id=141)
> org.eclipse.xtext.scoping.impl.ImportNormalizer.resolve(org.eclipse.xtext.naming.QualifiedName)
> line: 59
> org.eclipse.xtext.scoping.impl.ImportScope.getLocalElementsByName(org.eclipse.xtext.naming.QualifiedName)
> line: 150
> org.eclipse.xtext.scoping.impl.ImportScope(org.eclipse.xtext.scoping.impl.AbstractScope).getElements(org.eclipse.xtext.naming.QualifiedName)
> line: 127
> org.eclipse.xtext.scoping.impl.ScopeBasedSelectable.getExportedObjects(org.eclipse.emf.ecore.EClass,
> org.eclipse.xtext.naming.QualifiedName, boolean) line: 37
> org.eclipse.xtext.scoping.impl.ImportScope.getLocalElementsByName(org.eclipse.xtext.naming.QualifiedName)
> line: 152
> org.eclipse.xtext.scoping.impl.ImportScope.getSingleLocalElementByName(org.eclipse.xtext.naming.QualifiedName)
> line: 140
> org.eclipse.xtext.scoping.impl.ImportScope(org.eclipse.xtext.scoping.impl.AbstractScope).getSingleElement(org.eclipse.xtext.naming.QualifiedName)
> line: 101
> org.eclipse.xtext.scoping.impl.ImportScope(org.eclipse.xtext.scoping.impl.AbstractScope).getSingleElement(org.eclipse.xtext.naming.QualifiedName)
> line: 104
> org.eclipse.xtext.scoping.impl.ImportScope(org.eclipse.xtext.scoping.impl.AbstractScope).getSingleElement(org.eclipse.xtext.naming.QualifiedName)
> line: 104
> vsa.marvin.mod.common.services.MarvinLinkingService.getLinkedObjects(org.eclipse.emf.ecore.EObject,
> org.eclipse.emf.ecore.EReference, org.eclipse.xtext.nodemodel.INode)
> line: 101
> vsa.marvin.mod.common.resource.DelegatingXtextResource(org.eclipse.xtext.linking.lazy.LazyLinkingResource).getEObject(java.lang.String)
> line: 169
> vsa.marvin.mod.common.resource.DelegatingXtextResource.getEObject(java.lang.String)
> line: 85
> vsa.marvin.mod.common.resource.DelegatingXtextResource(org.eclipse.xtext.linking.lazy.LazyLinkingResource).resolveLazyCrossReference(org.eclipse.emf.ecore.InternalEObject,
> org.eclipse.emf.ecore.EStructuralFeature) line: 138
> vsa.marvin.mod.common.resource.DelegatingXtextResource(org.eclipse.xtext.linking.lazy.LazyLinkingResource).resolveLazyCrossReferences(org.eclipse.xtext.util.CancelIndicator)
> line: 102
> org.eclipse.xtext.EcoreUtil2.resolveLazyCrossReferences(org.eclipse.emf.ecore.resource.Resource,
> org.eclipse.xtext.util.CancelIndicator) line: 417
> org.eclipse.xtext.validation.ResourceValidatorImpl.resolveProxies(org.eclipse.emf.ecore.resource.Resource,
> org.eclipse.xtext.util.CancelIndicator) line: 127
> org.eclipse.xtext.validation.ResourceValidatorImpl.validate(org.eclipse.emf.ecore.resource.Resource,
> org.eclipse.xtext.validation.CheckMode,
> org.eclipse.xtext.util.CancelIndicator) line: 62
> org.eclipse.xtext.ui.editor.validation.ValidationJob$1.exec(org.eclipse.xtext.resource.XtextResource)
> line: 79
> org.eclipse.xtext.ui.editor.validation.ValidationJob$1.exec(java.lang.Object)
> line: 1
> org.eclipse.xtext.ui.editor.model.XtextDocument$XtextDocumentLocker(org.eclipse.xtext.util.concurrent.AbstractReadWriteAcces<P>).readOnly(org.eclipse.xtext.util.concurrent.IUnitOfWork<T,P>)
> line: 32
> org.eclipse.xtext.ui.editor.model.XtextDocument.readOnly(org.eclipse.xtext.util.concurrent.IUnitOfWork<T,org.eclipse.xtext.resource.XtextResource>)
> line: 86
> org.eclipse.xtext.ui.editor.validation.ValidationJob.createIssues(org.eclipse.core.runtime.IProgressMonitor)
> line: 75
> org.eclipse.xtext.ui.editor.validation.ValidationJob.run(org.eclipse.core.runtime.IProgressMonitor)
> line: 64
> org.eclipse.core.internal.jobs.Worker.run() line: 54
>
>
>
>
|
|
|
| Re: Problems with imports after migrating to xtext 2.0 [message #1146534 is a reply to message #719459] |
Sun, 20 October 2013 03:52 |
| Eclipse User |
|
|
|
Dear All,
I need your favor or suggestion regarding migrate the xtext version from 1.0.1 to 2.3.0 in custom application.
I followed all following process for migrate the xtext version.
1. Delete the old plug-ins and update the latest plug-ins in target platform.
2. Update the Plug-in Dependencies and Import Statements.
3. Introduction of the Qualified Name.
4. Changes in the index and in find references.
5. Rewritten Node Model.
6. AutoEditStrategy.
7. Other Noteworthy API Changes
To consider the above steps, I started the work with Eclipse-4.2, Which has a xtext-2.3.0 dependency. Successfully I completed the all above steps and removed the compilation error.
Problem: After that I start the testing and getting below error Messages:
[XtextLinkingDiagnostic: null:6 Couldn't resolve reference to Material 'MPS_RECUR'.,
XtextLinkingDiagnostic: null:9 Couldn't resolve reference to Cstic 'NUM_OF_ALLOC'.,
XtextLinkingDiagnostic: null:15 Couldn't resolve reference to Cstic 'INSTANCE_NUM'.,
XtextLinkingDiagnostic: null:14 Couldn't resolve reference to Class 'ALLOC'.]
|
|
|
Goto Forum:
Current Time: Wed Jul 23 14:13:54 EDT 2025
Powered by FUDForum. Page generated in 0.03511 seconds |
Home