DSL Packaging and Deployment - Eclipse Modeling Project: A Domain-Specific Language Toolkit - page 311

In the Gen Plugin element for each diagram, we set the Name property and
Provider appropriately—in this case, a friendly name for each plug-in and
Eclipse.org for the provider. We also set Printing Enabled to true
because it's not enabled by default. For the Version property, we leave the
default 1.0.0.qualifier value because the qualifier suffix will be replaced
by a time stamp during export and, eventually, during our headless PDE build.
By default, Graphical Modeling Framework (GMF) places its generated new
diagram wizards in the Examples category. We want each of our requirements
editors to fall under our new requirements category, so we can modify the dia-
gram .gmfgen models to specify org.eclipse.requirements.wizards.
category for the Gen Diagram element's Creation Wizard Category ID
property, found in the Editor category. Eclipse Modeling Framework (EMF), on
the other hand, places its generated creation wizards in its own Example EMF
Model Creation Wizards category with the ID org.eclipse.emf.ecore.
wizard.category.ID . Unfortunately, the EMF genmodel provides only a
Boolean property either to generate a wizard or not, with no property to specify
the category it should fall under. We don't expect to change it often, and because
EMF does not overwrite plug-in manifest files upon regeneration, we can make
the change in the generated org.eclipse.requirements.model.editor/
plugin.xm l file. Delete the nested category element from the *. newWizards
contribution and change the wizard element's category attribute to
org.eclipse.requirements.wizards.category .
We created a general preference category for our Requirements product that
we now need to leverage in our generated diagram preferences. Unfortunately, the
Gen Standard Preference Page element in the GMF generator model does
not enable us to specify the parent category . We can produce a decorator model
and custom templates to provide a generated approach, or we can simply add to
each generated plug-in manifest the org.eclipse.requirements.prefer-
ences.category ID as the root page's category . After doing so, we see
each diagram preferences under a common Requirements group, as shown in
Figure 8-1.
Finally, not all string values can be adjusted in the generator model. This
forces us to make final polish tweaks to the message.properties file in our
generated diagram. For example, our color modeling diagram is called dnc
Diagram in our new diagram wizard. Many of the default namings come from
the underlying domain model—in this case, our dnc package. After using these
and some other polishing items, we're ready to specify a product definition and
export it for testing and use.