Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Couldn't resolve reference to EPackage with plug-ins in different folders
Couldn't resolve reference to EPackage with plug-ins in different folders [message #559999] Mon, 20 September 2010 16:33 Go to next message
Sébastien  Gandon is currently offline Sébastien GandonFriend
Messages: 184
Registered: July 2009
Senior Member
Hello,
I have a grammar importing multiple ecore files :
import "platform:/resource/org.talend.model/model/TalendFile.ecore" as talendFile
import " platform:/resource/org.talend.designer.mapper/model/mapper.e core " as mapperFile
import " platform:/resource/org.talend.designer.dbmap/model/dbmap.eco re " as dbmapFile
import "http://www.eclipse.org/emf/2003/XMLType" as type
import "http://www.eclipse.org/emf/2002/Ecore" as ecore

but when I generate I have the error
Couldn't resolve reference to EPackage 'platform:/resource/org.talend.model/model/TalendFile.ecore'

I have looked at this forum and it is explaning that the workflow is using specific platform URI resolver defined with this
Workflow {
bean = StandaloneSetup {
platformUri = "${runtimeProject}/.."
}
.......

The problem with my setup is that my plug-ins are imported from different folder location and ../ is not a common folder for my plugins.
If I use the nsURI in the xtext definition, then the editor does not resolve them because they are not registered in the workbench.

How can I solve my problem please.

Thank you.

SeB.

Re: Couldn't resolve reference to EPackage with plug-ins in different folders [message #560101 is a reply to message #559999] Tue, 21 September 2010 08:32 Go to previous messageGo to next message
Meinte Boersma is currently offline Meinte BoersmaFriend
Messages: 434
Registered: July 2009
Location: Leiden, Netherlands
Senior Member
Please see this post: http://www.eclipse.org/forums/index.php?t=msg&goto=55431 8

Changing the nsUri for the import statements from platform URIs to the actual namespace URIs should do the trick.


Re: Couldn't resolve reference to EPackage with plug-ins in different folders [message #560116 is a reply to message #560101] Tue, 21 September 2010 09:10 Go to previous messageGo to next message
Sébastien  Gandon is currently offline Sébastien GandonFriend
Messages: 184
Registered: July 2009
Senior Member
As I mentionned in the original post, setting the nsURI in the import makes the Editor fail to resolve them as they are not registered in the current workbench.

Any other ideas apart from movind the plug-ins in the same folder ?
Re: Couldn't resolve reference to EPackage with plug-ins in different folders [message #560136 is a reply to message #560116] Tue, 21 September 2010 10:02 Go to previous messageGo to next message
Meinte Boersma is currently offline Meinte BoersmaFriend
Messages: 434
Registered: July 2009
Location: Leiden, Netherlands
Senior Member
Sorry, read a bit too fast...

You could try and use the URI map facility of StandaloneSetup and create the same URI map in the workspace. It's a long time since I used that, though (and only needed it for UML), and I can't remember any particular pitfalls there.


Re: Couldn't resolve reference to EPackage with plug-ins in different folders [message #560142 is a reply to message #560136] Tue, 21 September 2010 10:38 Go to previous messageGo to next message
Sébastien  Gandon is currently offline Sébastien GandonFriend
Messages: 184
Registered: July 2009
Senior Member
Could you be more specific, I tried to configure the StandaloneSetup UriMap but did not work any better.
Workflow {
bean = StandaloneSetup {
platformUri = "${runtimeProject}/.."
uriMap={from="platform:/resource/org.talend.model/model/TalendFile.ecore " to=" org.talend.designer.core.model.utils.emf.talendfile.TalendFi lePackage "

}}
I mapped the URI with the EPackage class but this does not work.

And also what do you mean by creating the same URI map in the workspace ?
Re: Couldn't resolve reference to EPackage with plug-ins in different folders [message #560150 is a reply to message #560142] Tue, 21 September 2010 11:09 Go to previous messageGo to next message
Meinte Boersma is currently offline Meinte BoersmaFriend
Messages: 434
Registered: July 2009
Location: Leiden, Netherlands
Senior Member
seb.fr wrote on Tue, 21 September 2010 12:38

And also what do you mean by creating the same URI map in the workspace ?

Ah, I remember: last time I worked with this, I was using IBM's RSM which has the ability to define path maps inside the Eclipse-derived tooling, but vanilla Eclipse doesn't have this, AFAIK.

An (somewhat related) example of the use of URI/path maps: http://kathayat.wordpress.com/2007/07/26/emf-howtos/ The syntax you're trying to use, looks correct but you'll have to map something like "pathmap:/externals1" to "file:/..." being an URI pointing to the physical location.

The editor's behavior on this is governed by what the Xtext builder can find by looking at the effective classpath, so maybe you can simply link the external files to it?


Re: Couldn't resolve reference to EPackage with plug-ins in different folders [message #560151 is a reply to message #560150] Tue, 21 September 2010 11:13 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14665
Registered: July 2009
Senior Member
Hi,

i guess what you want to do is something like:

Workflow {
    bean = StandaloneSetup {
		platformUri = "${runtimeProject}/.."
		uriMap = {
			from="platform:/resource/test.emf/model/test.ecore"
			to="file:/home/dietrich/Downloads/test.emf/model/test.ecore"
		}
	}

	...

			// generates Java API for the generated EPackages 
			fragment = ecore.EcoreGeneratorFragment {
			 	referencedGenModels = "file:/home/dietrich/Downloads/test.emf/model/test.genmodel"
			}

		...
}


~Christian


Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Couldn't resolve reference to EPackage with plug-ins in different folders [message #560163 is a reply to message #560151] Tue, 21 September 2010 12:06 Go to previous messageGo to next message
Sébastien  Gandon is currently offline Sébastien GandonFriend
Messages: 184
Registered: July 2009
Senior Member
by doing this mapping to actual files this workflow definition will only work on my machine and not on my collegues.
Isn't it way to map the import URI the EPackage class in the workflow file so that the standalone execution will resolve the URI by looking at the classpath class defined?

I tend to think that defining a mapping with an absolute file path is not a good solution.
Re: Couldn't resolve reference to EPackage with plug-ins in different folders [message #624952 is a reply to message #560163] Wed, 22 September 2010 06:42 Go to previous messageGo to next message
Meinte Boersma is currently offline Meinte BoersmaFriend
Messages: 434
Registered: July 2009
Location: Leiden, Netherlands
Senior Member
Whether the path is absolute or relative doesn't matter anyway in case the relative path isn't constant across everyone having a development environment. I haven't tried relative paths with pathmaps, so they might work alright.


Re: Couldn't resolve reference to EPackage with plug-ins in different folders [message #627960 is a reply to message #624952] Thu, 23 September 2010 07:39 Go to previous message
Sébastien  Gandon is currently offline Sébastien GandonFriend
Messages: 184
Registered: July 2009
Senior Member
Year, your are right,
this is why I do not want a solution with paths at all, what about mapping URIs with EPackage class ?
this would work the same way in both the IDE and the external workflow generation.

I have tried the classpath:/ protocol but it does work in the IDE workbench editor.

Anyone has a solution or should I fill a bug ?


SeB.
Previous Topic:best practice - applying formatting?
Next Topic:my last problem with typing
Goto Forum:
  


Current Time: Wed Apr 24 14:52:42 GMT 2024

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

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

Back to the top