New feature and plugin integration (developer)
This page describes basic information for plug-in integration.
# Basics
All of the following are specified in during plug-in creation or in the manifest file.
Each plug-in that is added to the tool-chain has to belong to package org.openetcs. Sub-packages are named feature_name.plugin_name and all names should be lowercase. So for example a the package transform of the datadictionary feature will be org.openetcs.datadictionary.transform.
The feature itself should be named feature giving org.openetcs.datadictionary.feature for the datadictionary example.
Before first push: Ensure that the plug-in is located in the right place before pushing your changes to the repository, this may not be the case if your workspace and git repository are different directories.
Each package and feature has a version number that is used by the tool-chain. It has three component a.b.c where
- a is the major version number and marks not retro-compatible API changes;
- b is the minor version number and marks retro-compatible API changes with new public API additions;
- c is the patch version number and corresponds to bug corrections, optimizations, etc. There are no public API changes.
The name should be a short and informative name used for plug-in description. For example bundle name of plug-in org.openetcs.datadictionary.transform is Bitwalker to Data Dictionary UML Transformer. This name will be shown in product loaded plug-in list.
## Vendor Plug-in provider / developer team name.
Each plug-in should be documented in the wiki. This can be done using a specific page for the plug-in or updating feature documentation page.
## Use cases and user stories It is recommended to provide use cases, or user stories, showing the plug-in goal and usage.
For example for the org.openetcs.datadictionary.transform plug-in, a use case would be:
The user loads a Bitwalker XML file, the plug-in transforms it into a Data Dictionary SysML model that is usable by modeling team.
A user story would be:
As an user I want to build a Data Dictionary model form a Bitwalker XML file, the plug-in performs the transformation.
Each time a new build is performed the features should be tested. This test should be documented on a feature basis or plug-in basis if the plug-in is standalone.
An example for the org.openetcs.datadictionary.transform plug-in :
After a new build, use the Data Dictionary transform button to open a Bitwalker XML file. This should be performed for subsets 026-7 and 026-8. We need to ensure that:
- A model is produced;
- The SysML profile is applied;
- ValueType stereotypes are applied on Variables in subset 026-7.