Core Extension Points - Allows customization of the editor for a specific Target Runtime platform.
UI Extension Points - Additional extension points specific to the UI.
All of these extension elements may also be defined within a Workspace Project instead of, or in addition to, an extension plug-in. When the editor starts up, all XML files contained in the project folder named ".bpmn2config" are loaded. These configuration files override default behavior provided by the editor core or other contributing plug-ins defining the Target Runtime for which the Project is configured. As an example, suppose that you have installed the BPMN2 Modeler from eclipse.org along with a third-party vendor supplied extension plug-in for the "Foo Target Runtime" with the ID org.foo.runtime. Also, the "Foo Target Runtime" defines the target namespace "http://org.foo" for BPMN2 extensions. After configuring your Workspace Project to use the "Foo Target Runtime" (see the discussion about setting Project Preferences in the User's Guide), it is possible to customize the editor behavior using the following configuration file placed in the Project's ".bpmn2config" folder:
<?xml version="1.0" encoding="UTF-8"?> <runtime id="org.foo.runtime"> <modelExtension id="org.foo.runtime.my.endpoint.extension" uri="http://org.foo/extensions" name="My Webservice EndPoint Extension" type="EndPoint"> <property name="serviceAddress" type="ServiceAddress"> <value> <property name="port" type="EString" /> <property name="binding" type="BindingType:EEnum" value="SOAP HTTP" /> </value> </property> </modelExtension> </runtime>
This will decorate the BPMN2 EndPoint model element with an extension element named "serviceAddress"; that element will have two attributes named "port" and "binding". The resulting EndPoint definition XML might look like this in a bpmn2 file:
<bpmn2:endPoint id="EndPoint_1"> <bpmn2:extensionElements> <extensions:serviceAddress extensions:port="RequestPortType" extensions:binding="HTTP"/> </bpmn2:extensionElements> </bpmn2:endPoint>
There are a couple of issues to consider, however, when using configuration files to extend model elemnts:
- Existing process files may no longer be readable if model extension definitions are removed from configuration files; these extension elements may have to be removed from process files "by hand" using a text or XML editor.
- The BPMN2 editor may have to be closed and reopened for some of these configuration file changes to take effect.
- Your configuration files will have to be distributed along with your bpmn2 process files if you are collaborating on a process definition.
A final note: these configuration files are intended to be used primarily by plug-in developers to test out various BPMN2 Modeler extension points, rather than in a production environment where process file integrity is crucial.