| [Xpand] unresolved proxy referincing a model with "platform:/plugin/..." schema [message #513190] |
Tue, 09 February 2010 05:15  |
Eclipse User |
|
|
|
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!
|
|
|
|
|
| Re: [Xpand] unresolved proxy referincing a model with "platform:/plugin/..." schema [message #513316 is a reply to message #513213] |
Tue, 09 February 2010 13:17  |
| Eclipse User |
|
|
|
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!
|
|
|
| Re: [Xpand] unresolved proxy referincing a model with "platform:/plugin/..." schema [message #513339 is a reply to message #513316] |
Tue, 09 February 2010 14:16 |
| Eclipse User |
|
|
|
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!
|
|
|
| Re: [Xpand] unresolved proxy referincing a model with "platform:/plugin/..." schema [message #513438 is a reply to message #513339] |
Wed, 10 February 2010 03:55 |
| Eclipse User |
|
|
|
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.
|
|
|
Powered by
FUDForum. Page generated in 0.37123 seconds
Home