Eclipse Community Forums: M2T (model-to-text transformation) » [Xpand] unresolved proxy referincing a model with "platform:/plugin/..." schema

Home » Modeling » M2T (model-to-text transformation) » [Xpand] unresolved proxy referincing a model with "platform:/plugin/..." schema

Show: Today's Messages :: Show Polls :: Message Navigator

[Xpand] unresolved proxy referincing a model with "platform:/plugin/..." schema [message #513190]

Tue, 09 February 2010 10:15

Mauro Antonaci

Messages: 12
Registered: February 2010

Junior Member

Hello,
we have a problem in our code generation project (model to text) that seems to be caused by the way we do the source model composition (main model referencing a reusable sub-model provided in a separate plugin, and referenced via "platform:/plugin" uri-schema). We need this approach (providing reusable fragments as third-party plugins) to conform to our organization: a central group that provides reusable compoents and many development groups that uses them to build various applications.

My question is: is this feasible and we are only doing something wrong (what?) or are we asking Xpand+emf something impossible, so we have to change our component distribution strategy?

The problem: it seems that the cross-model reference is not resolved when the main model is loaded by the Reader (symptom: xpand template get a null value instead of the referred element when tryng to do the job, so the code generation fails).

Both models refers to the same ecore metamodel and the sub-model is included without problems into the main model with the EMF editor command "load resource..." writing by hand the full URI (platform:/plugin/<plugin>/<path>...).

The same model composition works fine if the referenced model is in the same OAW project (we are using OAW 4.3.1 on galileo) and referenced with a relative path (load resource -> browse workspace).

The oaw workflow is the following:

<?xml version="1.0"?>
<workflow>
	<property name="target-platform" value="struts2"/>
	<property name="src-gen" value="../${targetProjectName}" />	
	<bean class="org.eclipse.mwe.emf.StandaloneSetup" >	
		<platformUri value=".." />
		<registerGeneratedEPackage value="it.csi.mddtools.guigen.GuigenPackage"/>
	</bean>
	<!-- load model and store it in slot 'model' -->
	<component class="org.eclipse.mwe.emf.Reader">
		<uri value="platform:/resource/${model}" />
		<modelSlot value="model" />
	</component>
	<!--  generate code -->
	<component class="org.openarchitectureware.xpand2.Generator" id="mygenerator">
		<metaModel idRef="mm"/>
		<expand
			value="template::${target-platform}::Main::main FOR model" />
		
		<!--  protected regions configurator --> 
	    <prSrcPaths value="${src-gen}" /> 
	    <prDefaultExcludes value="true" /> 
	    <prExcludes value="*.jar, *.svn-base, .metadata" />
		<outlet path="${src-gen}" >
			<postprocessor class="org.openarchitectureware.xpand2.output.JavaBeautifier" />
		</outlet>
	</component>
	
</workflow>

Any help?

P.S: eclipse+EMF+OAW is a fantastic toolset: the only problem is that it works wery well... so we stretch it to the limit!

Report message to a moderator

Re: [Xpand] unresolved proxy referincing a model with "platform:/plugin/..." schema [message #513195 is a reply to message #513190]

Tue, 09 February 2010 10:27

Karsten Thoms

Messages: 762
Registered: July 2009
Location: Dortmund, Germany

Senior Member

Since MWE does not run in an OSGi environment plugin URIs are not known. They have to be mapped to resource URIs, and you need the underlying .ecore file for this accessible (also) as resource.

The mapping is done in the StandaloneSetup like follows:

<bean class="org.eclipse.emf.mwe.utils.StandaloneSetup" platformUri="${runtimeProject}/..">
   <uriMap from="platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore" to="platform:/resource/fast.encoder.dsl.dsl/model/Ecore.ecore" />
</bean>

Regards,
~Karsten

Need professional support for Xtext, EMF, Eclipse IDE?
Go to: http://devhub.karakun.com
Twitter : @kthoms
Blog : www.karsten-thoms.de

Report message to a moderator

Re: [Xpand] unresolved proxy referincing a model with "platform:/plugin/..." schema [message #513213 is a reply to message #513195]

Tue, 09 February 2010 06:52

Ed Merks

Messages: 33264
Registered: July 2009

Senior Member

Guys,

It should even be possible to map
platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore to
jar:file:/../org.eclipse.emf.ecore_xyz.jar!/model/Ecore.ecor e, i.e., to
redirect it to the jar being used in the running processes.

Karsten Thoms wrote:
> Since MWE does not run in an OSGi environment plugin URIs are not
> known. They have to be mapped to resource URIs, and you need the
> underlying .ecore file for this accessible (also) as resource.
>
> The mapping is done in the StandaloneSetup like follows:
>
> <bean class="org.eclipse.emf.mwe.utils.StandaloneSetup"
> platformUri="${runtimeProject}/..">
> <uriMap
> from="platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore "
> to="platform:/resource/fast.encoder.dsl.dsl/model/Ecore.ecore " />
> </bean>
>
>
> Regards,
> ~Karsten

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: [Xpand] unresolved proxy referincing a model with "platform:/plugin/..." schema [message #513316 is a reply to message #513213]

Tue, 09 February 2010 18:17

Mauro Antonaci

Messages: 12
Registered: February 2010

Junior Member

Thanks, your answers are very useful for me to understand better my problem: I did not know this limitation on plugin URI.

The first suggestion (by Karsten) requires the presence of the sub-model in the workspace (so that it can be found after the uri-mapping), and this violates our main constraint ("hide the sub-model inside the plugin!"). If we could remove this constraint, we could reference sub-model as a workspace resource so the uri mapping would be no more needed and all will work fine, but unfortunately we can't.

The refined suggestion (by Ed), seems to work (with some extra trick) and is compliant with our main constraint, because there is no need to copy sub-model into the workspace, but it can be referenced as plugin uri (with each plugin uri remapped to jar resource):

<uriMap from="platform:/plugin/<plugin name>/<path to submodel inside plugin>" to="jar:file:/<full path to plugin directory>/<jar name_xyz>.jar!/<path to submodel inside plugin>" />

The extra trick needed is that, even if the EMF editor shows the included resource as "platform/plugin/.." looking in the source code we found an unexpected behavior: the editor resolved the plugin uri to a relative path (with a lot of "../.." depending on the relative position between the workspace and the eclipse installation):

...
<panelDef href="../../../../../../../plugin/misctestcrt/model/pdefplugin/pdefplugin/mypdef.guigen#/"/>
...

and this is obviously not good (and does not work). But reverting by hand (with a text editor) the href to the original plugin uri, the Ed's solution works fine.

So a big step forward is done: thanks.

Now my next problem is: find a better (more portable) way to specify in the oaw file the path of the plugin jar in the right side of the URI mapping. I will try one of the following:
1) define a workflow property like ${eclipse_home} and using it in the remapped uri
2) subclass the StandaloneSetup class so it puts automatically all the uri mapping needed (if I will be able to do some discovery on referenced plugins, I don't know if it's possibile/easy in a running oaw-workflow).

Thank you for your help!

Report message to a moderator

Re: [Xpand] unresolved proxy referincing a model with "platform:/plugin/..." schema [message #513339 is a reply to message #513316]

Tue, 09 February 2010 19:16

Ed Merks

Messages: 33264
Registered: July 2009

Senior Member

Mauro,

The recent posting from today in the EMF newsgroup about "Persisting
loaded resources across two models - pathmap is lost" might be useful
for you to understand how relative paths are produced or controlled.

Mauro wrote:
> Thanks, your answers are very useful for me to understand better my
> problem: I did not know this limitation on plugin URI.
> The first suggestion (by Karsten) requires the presence of the
> sub-model in the workspace (so that it can be found after the
> uri-mapping), and this violates our main constraint ("hide the
> sub-model inside the plugin!"). If we could remove this constraint, we
> could reference sub-model as a workspace resource so the uri mapping
> would be no more needed and all will work fine, but unfortunately we
> can't.
>
> The refined suggestion (by Ed), seems to work (with some extra trick)
> and is compliant with our main constraint, because there is no need to
> copy sub-model into the workspace, but it can be referenced as plugin
> uri (with each plugin uri remapped to jar resource):
>
>
> <uriMap from="platform:/plugin/<plugin name>/<path to submodel inside
> plugin>" to="jar:file:/<full path to plugin directory>/<jar
> name_xyz>.jar!/<path to submodel inside plugin>" />
>
>
> The extra trick needed is that, even if the EMF editor shows the
> included resource as "platform/plugin/.." looking in the source code
> we found an unexpected behavior: the editor resolved the plugin uri to
> a relative path (with a lot of "../.." depending on the relative
> position between the workspace and the eclipse installation):
>
>
> ..
> <panelDef
> href=" ../../../../../../../plugin/misctestcrt/model/pdefplugin/pde fplugin/mypdef.guigen#/ "/>
>
> ..
>
>
> and this is obviously not good (and does not work). But reverting by
> hand (with a text editor) the href to the original plugin uri, the
> Ed's solution works fine.
>
> So a big step forward is done: thanks.
>
> Now my next problem is: find a better (more portable) way to specify
> in the oaw file the path of the plugin jar in the right side of the
> URI mapping. I will try one of the following:
> 1) define a workflow property like ${eclipse_home} and using it in the
> remapped uri
> 2) subclass the StandaloneSetup class so it puts automatically all the
> uri mapping needed (if I will be able to do some discovery on
> referenced plugins, I don't know if it's possibile/easy in a running
> oaw-workflow).
>
> Thank you for your help!

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: [Xpand] unresolved proxy referincing a model with "platform:/plugin/..." schema [message #513438 is a reply to message #513339]

Wed, 10 February 2010 08:55

Mauro Antonaci

Messages: 12
Registered: February 2010

Junior Member

Yes, thanks. It is useful to solve the unexpected uri resolution (so the "extra trick" that I mentioned in my previopus post is no more needed):
I have customized the Editor plugin of my metamodel (class <my metamodel>Editor, method doSave()) so that the suggested option is used, and now my editor preserves the original uri.

 * @generated NOT
	 */
	@Override
	public void doSave(IProgressMonitor progressMonitor) {
		// Save only resources that have actually changed.
		//
		final Map<Object, Object> saveOptions = new HashMap<Object, Object>();
		saveOptions.put(Resource.OPTION_SAVE_ONLY_IF_CHANGED, Resource.OPTION_SAVE_ONLY_IF_CHANGED_MEMORY_BUFFER);
		// added for eclipse bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=232663
		saveOptions.put(XMLResource.OPTION_URI_HANDLER, new URIHandlerImpl.PlatformSchemeAware());

It was also useful the info about this (fixed) bug:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=232663

that addresses a similar issue.

Report message to a moderator

Previous Topic:	Workflow problem on Windows after upgrade to M5
Next Topic:	equals-operation on custom datatypes

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sat Dec 21 16:55:29 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter