Community
Participate
Working Groups
I've got a (minor) problem with the generated MANIFEST.MF file. The EMF genmodelis used to generate three bundles: tld.xyz.core, tld.xyz.edit and tld.xyz.editor. The MANIFEST.MF file generated by GMF contains Require-Bundle: org.eclipse.core.runtime, [...] tld.xyz.core;visibility:=reexport, tld.xyz.core.edit;visibility:=reexport, org.eclipse.gmf.runtime.draw2d.ui;visibility:=reexport, org.eclipse.draw2d;visibility:=reexport instead of Require-Bundle: org.eclipse.core.runtime, [...] tld.xyz.core;visibility:=reexport, tld.xyz.edit;visibility:=reexport, org.eclipse.gmf.runtime.draw2d.ui;visibility:=reexport, org.eclipse.draw2d;visibility:=reexport - for the edit bundle, there's a ".core" inserted that shouldn't be there.
I believe there's wrong value for edit plugin id in your .genmodel Template for manifest.mf relies on values in .genmodel (genModel.getModelPluginID() and genModel.getEditPluginID()), no manual construction of plugin id takes place.
Although I can set the Model Plug-In ID in the .genmodel (it's set to tld.xyz.core), there's no property to set either the Edit Plug-In ID or the Editor Plug-In ID. It's only possible to set the target directories and the Plug-in Classes (both are correct - /tld.xyz.edit/src and tld.xyz.edit.Activator). Just to be sure, I've searched the .genmodel in the text editor - there's no String ".core.edit" in it. --> I'd say
Although I can set the Model Plug-In ID in the .genmodel (it's set to tld.xyz.core), there's no property to set either the Edit Plug-In ID or the Editor Plug-In ID. It's only possible to set the target directories and the Plug-in Classes (both are correct - /tld.xyz.edit/src and tld.xyz.edit.Activator). Just to be sure, I've searched the .genmodel in the text editor - there's no String ".core.edit" in it.
Sorry. Browser went crazy in mid-air. --> I'd say getEditPluginID() is just not written for this kind of arrangement: --snip-- public String getEditPluginID() { if (sameModelEditProject()) { return getModelPluginID(); } else { return getModelPluginID() + ".edit"; } } --snip-- Will there be a way to adjust the plugin IDs of Edit and Editor Plugins separately in the future?
Apparently, edit plug-in id is hardcoded in GenModelImpl (@see #getEditPluginID), while #generateEdit() ignores this setting and uses editDirectory instead.
Unless I misunderstand, this is all working as designed and there is simply a desire to be able to control the .edit plugin's ID directly via a property rather than having it be based purely on the model plugin's ID. So I'll mark this as an enhancement request.
Ed: I wished that feature for a long time. In fact, there are lots of time where products are cut into many parts by separating UI from models. For instance, i've got some models that are used internally in the runtime of my product, but can be edited in its SDK. Having the possibility to get : model plugin ID: org.smth.product.runtime.mymodel1 edit plugin ID: org.smth.product.ui.mymodel1.edit editor plugin ID: org.smth.product.ui.mymodel1.editor BTW, i think GMF has a unique "Package Name Prefix" that is used to derive the plugin ID, the package prefix and IMHO i find this more consistent with Eclipse way where most plugins have their ID equal to the root package of the java code it contains.
*** Bug 194769 has been marked as a duplicate of this bug. ***
I'd like to add own plugin dependencies to my generated edit plugin. Is there a mechanism similar to the Model Plug-in Variables property? Ed in the newsgroup: No, but that would kind of make sense for both edit and editor. It's indirectly related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=163597 so I suppose you could open a different feature request or add it to that existing one (since we need to add additional state features for the GenModel anyway to support the above so adding a bunch at once is a bit easier).
Support for plugin IDs for edit, editor, and tests projects as well as plugin variables for each has been committed to CVS for 2.4.
Fixed in I200801090807.
Move to verified as per bug 206558.
