|
|
|
|
Re: Packages should be imported by their namespace URI. [message #961276 is a reply to message #960813] |
Sun, 28 October 2012 05:55 |
Ed Merks Messages: 33216 Registered: July 2009 |
Senior Member |
|
|
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Ed,<br>
<br>
Comments below.<br>
<br>
<div class="moz-cite-prefix">On 27/10/2012 10:46 PM, Ed Willink
wrote:<br>
</div>
<blockquote cite="mid:k6hh84$dm5$1@xxxxxxxxe.org" type="cite">Hi
Sebastian
<br>
<br>
Ah! That index. That explains somethings, but
<br>
<br>
a) why do I have to use an index when in Xtext 2.0, I could
specify what I want explicitly? (no need to have index building
wasting my CPU cycles every time EGIT wakes up.)
<br>
</blockquote>
Because the grammars themselves depend on the index for importing
other grammars.<br>
<blockquote cite="mid:k6hh84$dm5$1@xxxxxxxxe.org" type="cite">
<br>
b) why do I have to add the Xtext nature to my model plugins, just
to be able to reference them via an index?
<br>
</blockquote>
Because projects in the workspace are indexed only if they have an
Xtext nature to save those CPU cycles if you don't want your project
indexed.<br>
<blockquote cite="mid:k6hh84$dm5$1@xxxxxxxxe.org" type="cite">
<br>
c) it doesn't work when A.xtext references B.ecore, which
references C.ecore, each in different plugins because
<br>
- C.ecore must be imported by nsURI from A.xtext to suit Xtext
indexing
<br>
- C.ecore must be referenced by relative path from B.ecore to suit
Ecore referencing
<br>
</blockquote>
I'm hopeful that between fixing these two bugs (the first committed
yesterday and the second pending review of the Xtext team) this
problem will be fully addressed.<br>
<blockquote><a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=220218">https://bugs.eclipse.org/bugs/show_bug.cgi?id=220218</a><br>
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=390411">https://bugs.eclipse.org/bugs/show_bug.cgi?id=390411</a><br>
</blockquote>
<br>
<blockquote cite="mid:k6hh84$dm5$1@xxxxxxxxe.org" type="cite">This
causes Xtext to fail with an unhelpfully conflicting model element
diagnostic. So I still get warnings, though not quite as many as
when using import 'platform:/resource/...' in conventional EMF
(and Xtext 2.0) style.
<br>
</blockquote>
I'd suggest making a small example along with the steps to reproduce
them so we can make sure that this problem disappears with the above
two issues addressed. I imagine it should be the case that either
platform:/resource or nsURI should work properly (because with the
first bugzilla addressed, the EMF models for all target platform
bundles will be visible as platform:/resource/<bundle-id>,
even the ones that aren't really physically in the workspace)...<br>
<blockquote cite="mid:k6hh84$dm5$1@xxxxxxxxe.org" type="cite">
<br>
Regards
<br>
<br>
Ed Willink
<br>
<br>
On 27/10/2012 15:44, Sebastian Zarnekow wrote:
<br>
<blockquote type="cite">The EPackages are looked up in the index
by their nsURI. Therefore you should always use that one. Things
from the workspace are preferred over packages from the target
platform which are in turn preferred over installed packages
from the workbench.
<br>
<br>
Hope that helps,
<br>
Sebastian
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.04784 seconds