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

Bug 326760

Summary: Models are not updated correctly when using ImportURIScoping
Product: [Modeling] TMF Reporter: Michael Zeising <michael>
Component: XtextAssignee: Jan Koehnlein <jan>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: clay, jan, sebastian.zarnekow, tmf.xtext-inbox
Version: unspecifiedFlags: sebastian.zarnekow: indigo+
Target Milestone: M5   
Hardware: PC   
OS: Windows 7   
Whiteboard:
Attachments:
Description Flags
Example Xtext projects
none
DSL file referencing another one
none
DSL file referenced by another one none

Description Michael Zeising CLA 2010-10-01 06:31:15 EDT 
Build Identifier: M20100909-0800

Hi,

when using the ImportURIScoping instead of namespaces, the elements exported by a referenced file are not updated correctly. You have to close both files and open them again so that the changes within the referenced file get visible to the origin file.

I'm using Xtext 1.0.1 with Helios SR1 but it was the same for Xtext 1.0.0 and Eclipse 3.6.0.

Thanks in advance!

Reproducible: Always

Steps to Reproduce:
1. Use ImportURIScoping
2. Open two files A and B, while A imports B
3. Add an element to B
4. Switch back to A and reference the new element
5. The changes are not visible to A and the new name is not found
Comment 1 Michael Zeising CLA 2010-10-01 06:34:52 EDT 
Created attachment 180038 [details]
Example Xtext projects
Comment 2 Michael Zeising CLA 2010-10-01 06:36:48 EDT 
Created attachment 180039 [details]
DSL file referencing another one
Comment 3 Michael Zeising CLA 2010-10-01 06:37:08 EDT 
Created attachment 180040 [details]
DSL file referenced by another one
Comment 4 Michael Clay CLA 2010-10-13 14:25:30 EDT 
import "platform:///resource/Test Models/models/b.mydsl"

entity X {
	ref Y
}


it works on the first time because the default registered o.e.e.e.resource.impl.URIHandlerImpl can handle such an URI although it's not a valid platform URL  (plaform:/ vs. platform:///).
Comment 5 Sebastian Zarnekow CLA 2010-12-06 03:52:04 EST 
The import uri validator should mark the illegal platform:/// ... uri. Does the user get feedback about the invalid format?
Comment 6 Michael Zeising CLA 2010-12-06 07:16:09 EST 
(In reply to comment #5)
> The import uri validator should mark the illegal platform:/// ... uri. Does the
> user get feedback about the invalid format?

No, the ImportUriValidator accepts the /// URIs, too. That's why I didn't recognize the error in the first place.
Comment 7 Sebastian Zarnekow CLA 2010-12-15 11:46:19 EST 
This didn't make it into M4. Preliminary scheduled for M5.
Comment 8 Jan Koehnlein CLA 2011-01-05 08:27:18 EST 
As you have already mentioned the problem is that 
  platform:///some/path...
is not a platform URI, i.e. URI.isPlatform() returns false as there is an empty (not null) authority segment. Consequently and correctly, the PlatformResourceURIHandler does not feel responsible for this URI. EMF behaves consistently here.

Unfortunately, the default URIHandlerImpl converts the URI to a URL and as Eclipse (not EMF) registered an PlatformURLHandler which is not as pedantic as EMF, this becomes a valid and openable URI :-(

In Xtext, we have lots of places where we assume platform URIs to be canonical for good reasons. I see two viable options:
1) We adapt the URIConverter strip authority segments when normalize platform URIs (two or three slashes after the colon).
2) We change the EcoreUtil2.isValidURI to return false if an URI has the "platform" scheme but is not a platform URI. 

Pushed alternative 2 and a test to MASTER.
Comment 9 Karsten Thoms CLA 2017-09-19 17:28:09 EDT 
Closing all bugs that were set to RESOLVED before Neon.0
Comment 10 Karsten Thoms CLA 2017-09-19 17:39:19 EDT 
Closing all bugs that were set to RESOLVED before Neon.0