Create a plugin for this compoent
Create a folder "model" for this component
Model
Principles
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 we will manipulate.
This extensively uses EAnnotation and ExtendedMetaData.
How to
Ecore
Create an ecore file in the "model" folder. Set Name and prefix as you want (a meaningful name for this component) set NS URI to the namespace of the component.
Type:
Create a <Component>Provides class extending the CDK Provides class (also works when extending JBI class).
Add EAnnotion on the type: source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData", create detail entry "name" with value blank (not null!).
Features
Features are the extension of the JBI element for this component. You can deduce them from the .xsd file of the component.
Create attribute for each attribute in XSD. Set its properties (Multipliciy, type...) according to the XSD. A good thing is to put the "Unsettable" to true is the same as XSD nillable, and then eSet(null) will be rendered as xsi:nill="true" in XML.
Create an EAnnotation with 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 Enum for XSD restricted String: the value of the "Literal" is the String as you want it to appear in XML.
GenModel
Create genmodel from .ecore: When asking for packages in the wizard, import other genmodel from jbi and cdk plugins, and mark all packages except the component one as "Referenced".
Select package: 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 genmodel rool: Set Copyright. Set Model > Model-Directory to src-model.
Generation
Generate from genmodel.
Ensure src-model folder is in your build.properties src path.
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.
Register 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.
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 bette than the current one.