Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 316586

Summary:	Incorrect XMI metamodelDeclarations hrefs in multi-package model
Product:	[Modeling] TMF	Reporter:	Ed Willink <ed>
Component:	Xtext	Assignee:	Jan Koehnlein <jan>
Status:	CLOSED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	jan, sebastian.zarnekow, sven.efftinge, tmf.xtext-inbox
Version:	1.0.0	Flags:	sebastian.zarnekow: helios+ jan: indigo+
Target Milestone:	M3
Hardware:	PC
OS:	Windows Vista
Whiteboard:

Description Ed Willink

2010-06-11 06:32:00 EDT

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.

Comment 1 Jan Koehnlein

2010-08-11 12:14:04 EDT

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

Comment 2 Ed Willink

2010-08-11 12:49:56 EDT

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.

Comment 3 Jan Koehnlein

2010-10-03 05:58:17 EDT

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.

Comment 4 Jan Koehnlein

2010-10-04 10:57:21 EDT

Removed old GrammarAccessFragment and made SubPackageAware implementation the default. 
Pushed to master: 88d7f5808cedf141ef1feed1c3c4756d8d32d6df

Comment 5 Jan Koehnlein

2010-11-05 11:20:58 EDT

No change necessary for SR2 (1.0.2)

Comment 6 Karsten Thoms

2017-09-19 17:20:53 EDT

Closing all bugs that were set to RESOLVED before Neon.0

Comment 7 Karsten Thoms

2017-09-19 17:32:10 EDT

Closing all bugs that were set to RESOLVED before Neon.0