Community
Participate
Working Groups
Given the following Xtext imports: import "http://www.eclipse.org/emf/2002/Ecore" as ecore import "platform:/resource/org.eclipse.ocl.examples.xtext.pivot/model/Pivot.ecore" as pivot import "platform:/resource/org.eclipse.ocl.examples.xtext.pivot/model/Pivot.ecore#//cst" as pivot_cst import "platform:/resource/org.eclipse.ocl.examples.xtext.pivot/model/Pivot.ecore#//model" as pivot_model import "platform:/resource/org.eclipse.ocl.examples.xtext.pivot/model/Pivot.ecore#//refs" as pivot_refs import "platform:/resource/org.eclipse.ocl.examples.xtext.pivot/model/Pivot.ecore#//utils" as pivot_utils import "platform:/resource/org.eclipse.ocl.examples.xtext.oclstdlib/model/OCLstdlibCST.ecore" the generated XMI contains <metamodelDeclarations xsi:type="xtext:ReferencedMetamodel" alias="ecore"> <ePackage href="http://www.eclipse.org/emf/2002/Ecore#/"/> </metamodelDeclarations> <metamodelDeclarations xsi:type="xtext:ReferencedMetamodel" alias="pivot"> <ePackage href="http://www.eclipse.org/ocl/3.0.0/Pivot/utils#/"/> </metamodelDeclarations> <metamodelDeclarations xsi:type="xtext:ReferencedMetamodel" alias="pivot_cst"> <ePackage href="http://www.eclipse.org/ocl/3.0.0/Pivot/utils#//cst"/> </metamodelDeclarations> <metamodelDeclarations xsi:type="xtext:ReferencedMetamodel" alias="pivot_model"> <ePackage href="http://www.eclipse.org/ocl/3.0.0/Pivot/utils#//model"/> </metamodelDeclarations> <metamodelDeclarations xsi:type="xtext:ReferencedMetamodel" alias="pivot_refs"> <ePackage href="http://www.eclipse.org/ocl/3.0.0/Pivot/utils#//refs"/> </metamodelDeclarations> <metamodelDeclarations xsi:type="xtext:ReferencedMetamodel" alias="pivot_utils"> <ePackage href="http://www.eclipse.org/ocl/3.0.0/Pivot/utils#//utils"/> </metamodelDeclarations> <metamodelDeclarations xsi:type="xtext:ReferencedMetamodel"> <ePackage href="http://www.eclipse.org/ocl/3.0.0/OCLstdlibCST#/"/> </metamodelDeclarations> [5 references to http://www.eclipse.org/ocl/3.0.0/Pivot/utils ...] Whereas moving the root import import "platform:/resource/org.eclipse.ocl.examples.xtext.pivot/model/Pivot.ecore" as pivot to follow all the nested imports gives 5 references to http://www.eclipse.org/ocl/3.0.0/Pivot which is fortunately correct and so provides a workaround. There are two bugs here. 1) The last import for the model file is used as the URI stem regardless of its appropriateness. 2) In the case where the root package is classifier-less (and so has no generated package), no error message is produced warning that hrefs cannot be produced reliably.
Support for nested EPackages in the EmptyPackageAwareGrammarAccessFragment. To make it clearer, I've moved the implementation from there to a new SubPackageAwareGrammarAccessFragment. Please replace your GrammarAccessFragment in the MWE2 workflow and verify if this fixes the bug. Note that our handling subpackages is quite hacky, that's why we don't make it the default. In general, we recommend not to nest EPackages at all, because it has a lot of funny effects on the package registry and the treatment of nsURIs, especially when empty packages are involved. See for example http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg41824.html
Sorry, but I have to work with layered packages: QVT, OCL, UML, MOF, ... It is totally normal. It seems very wrong that normal behaviour should have to use a non-normal fragment, whose impact is solely at compile time, so there is no performance reason for the partition.
We should really make EmptyPackageAwareGrammarAccessFragment the default as we did for the clustered builder in #325759. Indigo M3 should be early enough to test it properly.
Removed old GrammarAccessFragment and made SubPackageAware implementation the default. Pushed to master: 88d7f5808cedf141ef1feed1c3c4756d8d32d6df
No change necessary for SR2 (1.0.2)
Closing all bugs that were set to RESOLVED before Neon.0
