This section assumes you are familiar with Eclipse development.

Create a plugin for this component. For plug-ins edited by EBM WebSourcing, the naming convention is com.ebmwebsourcing.petals.services.componentAlias
Create a model folder in the plug-in.

Ecore Model (*.ecore)

First, you need to create a model extension of the JBI meta-model.
You will have to create a set of EStructuralFeatures that are "detached" from the static JBI type but that can be inserted into JBI class instances. Types are not really what is manipulated. This extensively uses EAnnotation and ExtendedMetaData.

• Create an ecore file in the "model" folder. Set Name and prefix as you want (a meaningful name for this component).
• Set the NS URI to the namespace of the component.

To create a type in the ecore model:

• Create a <Component>Provides class extending the CDK Provides class (also works when extending the JBI Provides class).
• Add an EAnnotation on the type.
  • Source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData"
  • Create a detail entry: "name" with a blank value (not null).

Types are one thing to maniulate in the ecore model. Features are another thing.
Features are the extension of the JBI element for this component. You can deduce them from the XML schemas of the component.
To add a feature in the ecore model:

• Create an EAttribute for each attribute and element in the XML schemas.
• Set its properties (Multipliciy, type...) according to the XML schemas.
• A good thing is to put the "Unsettable" to true (equivalent to nillable in the XML schema terminology). Unsettable elements will result in xsi:nill="true" when eSet(null); is called.

• Create an EAnnotation on the type.
  • Source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData".
  • The content of the details for this annotation specify the serialization of XML:
    • namespace: ##targetNamespace
    • kind: element
    • group: #group:0
    • name: <name of the element in XSD>

You can define enumerations too.

Generation Model (*.genmodel)

Create a genmodel file from the ecore.
When asking for packages in the wizard, import other genmodels from the JBI and CDK plug-ins. Mark all the packages, except the component one, as "Referenced".

Select the root package and edit its properties.
A good convention is to set "Base package" to the same value as Bundle name. Since it is the Java package, ensure it is not the same as a package already used.

• Select the genmodel root. Set the Copyright. Set the Model > Model-Directory to src-model.
• Right-click the root element and click Generate Model Code.
• Ensure src-model folder is in your build.properties src path.

Miscellaneous

Architecture

JBI.ecore enables extensibility by adding "groups" as EFeatureMap in extensible elements. These groups are placeholder for extensions.

When opening a JBI, there is not "resolution¨ of dynamic feature, so there is a routine that turns dynamic EStructuralFeature to the one defined in extension models. Extensions need to register their extended EMF package with the org.eclipse.emf.ecore.generated_package extension point.

Warnings

The extensions (EStructuralFeatures) are serialized in the initial order of insertion. It is convenient to set first all attributes with (meaningless or null) values to set up the order. Then next eSet will override the values and keep the order.

Notice that there is a hack in the editor to guarantee that CDK features are inserted before component ones.

Alternatives / Evolutions / Ideas

Instead of creating an Ecore file, you could use annotated classes directly, or use Dynamic EMF with EcoreFactory to create and manipulate your attributes.

Some other implementions may work, maybe better than the current one.
You can follow the following bug in which one there is a debate on how to make EMF support extensibility natively: https://bugs.eclipse.org/bugs/show_bug.cgi?id=369264