Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [XCORE] GMF: Resource '/org.eclipse.emf.ecore.xcore.lib/model/XcoreLang.xcore' does not exist.(Can't find file, even though the package is in the manifest.)
[XCORE] GMF: Resource '/org.eclipse.emf.ecore.xcore.lib/model/XcoreLang.xcore' does not exist. [message #1407095] Mon, 11 August 2014 21:50 Go to next message
Jack Greenfield is currently offline Jack GreenfieldFriend
Messages: 18
Registered: June 2014
Junior Member
(Cross posted to GMF forum)

I've migrated a set of ecore models used in a GMF editor to xcore, and I'm running into problems using them in GMF.

Specifically, the GMF map editor fails with "Resource '/org.eclipse.emf.ecore.xcore.lib/model/XcoreLang.xcore' does not exist."

Here is MANIFEST.MF:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: mybundle
Bundle-SymbolicName: mybundle; singleton:=true
Bundle-Version: 0.1.0.qualifier
Require-Bundle: org.eclipse.core.runtime,
org.eclipse.emf.ecore;visibility:=reexport,
org.eclipse.emf.ecore.xcore;visibility:=reexport,
org.eclipse.emf.ecore.xcore.lib;visibility:=reexport

Are there any guidelines for using GMF tools with Xcore?

[Updated on: Mon, 11 August 2014 21:52]

Report message to a moderator

Re: [XCORE] GMF: Resource '/org.eclipse.emf.ecore.xcore.lib/model/XcoreLang.xcore' does not exist. [message #1407195 is a reply to message #1407095] Tue, 12 August 2014 04:28 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30372
Registered: July 2009
Senior Member
Jack,

That might be caused by
https://bugs.eclipse.org/bugs/show_bug.cgi?id=437916 in which case a
maintenance build from
http://download.eclipse.org/modeling/emf/emf/updates/2.10 would likely
solve the problem. It's also possible that GMF's tools don't initialize
their resource set with the following (which has been available since 2.9):

resourceSet.getURIConverter().getURIMap().putAll(EcorePlugin.computePlatformURIMap(true));


On 11/08/2014 11:50 PM, Jack Greenfield wrote:
> I've migrated a set of ecore models used in a GMF editor to xcore, and
> I'm running into problems using them in GMF.
> Specifically, the GMF map editor fails with "Resource
> '/org.eclipse.emf.ecore.xcore.lib/model/XcoreLang.xcore' does not exist."
>
> Here is MANIFEST.MF:
>
> Manifest-Version: 1.0
> Bundle-ManifestVersion: 2
> Bundle-Name: mybundle
> Bundle-SymbolicName: mybundle; singleton:=true
> Bundle-Version: 0.1.0.qualifier
> Require-Bundle: org.eclipse.core.runtime,
> org.eclipse.emf.ecore;visibility:=reexport,
> org.eclipse.emf.ecore.xcore;visibility:=reexport,
> org.eclipse.emf.ecore.xcore.lib;visibility:=reexport
>
> Are there any guidelines for using GMF tools with Xcore?
Re: [XCORE] GMF: Resource '/org.eclipse.emf.ecore.xcore.lib/model/XcoreLang.xcore' does not exist. [message #1407494 is a reply to message #1407195] Tue, 12 August 2014 19:17 Go to previous messageGo to next message
Jack Greenfield is currently offline Jack GreenfieldFriend
Messages: 18
Registered: June 2014
Junior Member
Thanks for the quick reply, Ed. Updating didn't help. I've resorted to putting the xcore files in a separate project, generating ecore and genmodel files from them, and keeping all dependencies on xcore out of the plugin that contains the generated code. Sigh.

[Updated on: Tue, 12 August 2014 19:17]

Report message to a moderator

Re: [XCORE] GMF: Resource '/org.eclipse.emf.ecore.xcore.lib/model/XcoreLang.xcore' does not exist. [message #1407596 is a reply to message #1407494] Wed, 13 August 2014 01:58 Go to previous messageGo to next message
Jack Greenfield is currently offline Jack GreenfieldFriend
Messages: 18
Registered: June 2014
Junior Member
So, having unwound the mess, the general take away from the experience is that xcore is like kudzu. It touches every conceivable aspect of the delicate configuration of properties that makes a complex multi project editor build and run correctly. Using different genmodel property defaults and almost but not quite compatible replacements for ecore and genmodel constructs, it creates a seemingly bottomless pit of hard to track down problems. It's a shame, really, since the code editing is such a nice feature. Unfortunately, it really isn't a drop in replacement for ecore and genmodel in existing projects. I came close to rolling back everything, but after two days of hacking my way through the litany of issues, I finally have a running set of editors again, without losing the types I created so quickly using xcore. Close but no cigar.
Re: [XCORE] GMF: Resource '/org.eclipse.emf.ecore.xcore.lib/model/XcoreLang.xcore' does not exist. [message #1407627 is a reply to message #1407596] Wed, 13 August 2014 04:19 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30372
Registered: July 2009
Senior Member
Jack,

Comments below.

On 13/08/2014 3:58 AM, Jack Greenfield wrote:
> So, having unwound the mess, the general take away from the experience
> is that xcore is like kudzu. It touches every conceivable aspect of
> the delicate configuration of properties that makes a complex multi
> project editor build and run correctly.
I'm not sure what you mean by that...
> Using different genmodel property defaults
Actually it shares an initializer that's used for all newly created
*.genmodels, i.e.,
org.eclipse.emf.codegen.ecore.genmodel.GenModel.initialize(boolean), and
its designed to provide improved defaults, i.e., making use of
MinimalEObjectImpl.Container.
> and almost but not quite compatible replacements for ecore and
> genmodel constructs,
How so?
> it creates a seemingly bottomless pit of hard to track down problems.
Such as?
> It's a shame, really, since the code editing is such a nice feature.
> Unfortunately, it really isn't a drop in replacement for ecore and
> genmodel in existing projects.
In general, the only problem substantial problems in downstream
technologies can generally be tracked down to two things.

Not using the newer (EMF 2.9)
org.eclipse.emf.ecore.plugin.EcorePlugin.computePlatformURIMap(boolean)
to help initialize the resource set. This should be used regardless of
whether Xcore is involved because it's what ensures that models are
properly resolved to the models in the target platform rather than
models in the running IDE itself. You'll definitely notice if a
downstream technology hasn't switched over when you're using Xcore, so
you might see that as an Xcore-specific problem. The fix is trivial,
i.e., replace the call to the deprecated
org.eclipse.emf.ecore.plugin.EcorePlugin.computePlatformURIMap().

The other problem is an expectation in downstream technologies of which
file extensions contain which types of objects and the index of that
object within the resource. Again, generally trivial to fix, i.e., add
"xcore" where you currently have "ecore" and "genmodel", and use
org.eclipse.emf.ecore.util.EcoreUtil.getObjectByType(Collection<?>,
EClassifier) to pull out the root object.
> I came close to rolling back everything, but after two days of hacking
> my way through the litany of issues, I finally have a running set of
> editors again, without losing the types I created so quickly using
> xcore. Close but no cigar.
So if it's specifically a problem that I can fix in Xcore itself, you
ought to let me know, via bugzilla, what's wrong. If it's something GMF
needs to fix, you ought to open GMF bugzillas; I'd be interested to know
them so please add me to the CC list so I can suggest fixes.
Re: [XCORE] GMF: Resource '/org.eclipse.emf.ecore.xcore.lib/model/XcoreLang.xcore' does not exist. [message #1407849 is a reply to message #1407627] Wed, 13 August 2014 15:55 Go to previous message
Jack Greenfield is currently offline Jack GreenfieldFriend
Messages: 18
Registered: June 2014
Junior Member
Thanks for the quick reply, Ed. Answering your questions:

Ed Merks wrote on Wed, 13 August 2014 00:19

Jack,

Comments below.

On 13/08/2014 3:58 AM, Jack Greenfield wrote:
> So, having unwound the mess, the general take away from the experience
> is that xcore is like kudzu. It touches every conceivable aspect of
> the delicate configuration of properties that makes a complex multi
> project editor build and run correctly.
I'm not sure what you mean by that...
> Using different genmodel property defaults
Actually it shares an initializer that's used for all newly created
*.genmodels, i.e.,
org.eclipse.emf.codegen.ecore.genmodel.GenModel.initialize(boolean), and
its designed to provide improved defaults, i.e., making use of
MinimalEObjectImpl.Container.


What I mean is that many defaults changed using xcore out of the box, so that the generated code, MANIFEST.MF and build properties changed, causing build breakages and runtime exceptions.

As a simple example, the Runtime Jar property in the genmodel generated from an xcore is always TRUE, regardless of the setting in the xcore file. It may not seem like much, but it actually took quite a while for me to find that the cause of a resource load failure exception was an unexpected change in the generated build.properties due to the change in this default.

Quote:

> and almost but not quite compatible replacements for ecore and
> genmodel constructs,
How so?
> it creates a seemingly bottomless pit of hard to track down problems.
Such as?
> It's a shame, really, since the code editing is such a nice feature.
> Unfortunately, it really isn't a drop in replacement for ecore and
> genmodel in existing projects.
In general, the only problem substantial problems in downstream
technologies can generally be tracked down to two things.

Not using the newer (EMF 2.9)
org.eclipse.emf.ecore.plugin.EcorePlugin.computePlatformURIMap(boolean)
to help initialize the resource set. This should be used regardless of
whether Xcore is involved because it's what ensures that models are
properly resolved to the models in the target platform rather than
models in the running IDE itself. You'll definitely notice if a
downstream technology hasn't switched over when you're using Xcore, so
you might see that as an Xcore-specific problem. The fix is trivial,
i.e., replace the call to the deprecated
org.eclipse.emf.ecore.plugin.EcorePlugin.computePlatformURIMap().

The other problem is an expectation in downstream technologies of which
file extensions contain which types of objects and the index of that
object within the resource. Again, generally trivial to fix, i.e., add
"xcore" where you currently have "ecore" and "genmodel", and use
org.eclipse.emf.ecore.util.EcoreUtil.getObjectByType(Collection<?>,
EClassifier) to pull out the root object.


For those who support the tools for a living, it may not be a problem to modify downstream packages to deal with alignment problems, but for the toolsmith looking to use the tools for other projects, it isn't an option to spend the time required to track down and fix these issues.

Quote:

> I came close to rolling back everything, but after two days of hacking
> my way through the litany of issues, I finally have a running set of
> editors again, without losing the types I created so quickly using
> xcore. Close but no cigar.
So if it's specifically a problem that I can fix in Xcore itself, you
ought to let me know, via bugzilla, what's wrong. If it's something GMF
needs to fix, you ought to open GMF bugzillas; I'd be interested to know
them so please add me to the CC list so I can suggest fixes.


I would like to open some bugs. However, I'm under time pressure to get some designers delivered. Putting together good reproducible bug reports takes time, but I'll try to log some when time permits.

[Updated on: Wed, 13 August 2014 23:40]

Report message to a moderator

Previous Topic:Override getText for EClass
Next Topic:EMF compare
Goto Forum:
  


Current Time: Sun Aug 25 08:18:46 GMT 2019

Powered by FUDForum. Page generated in 0.02199 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top