refs 1841

- Fix editing of dynamically instantiated annotations
refs 1841

  - Get factory from EStructuralFeature types
  - Get default values from meta-model
  - Remove EStructuralFeatureDescriptor
  - Enable automatic construction of a EStructuralFeatureValueProviderBase for all features of a given EClass (instance key = field name)
- Unify creation of editing support
  - Merge Enum support into EStructuralFeatureValueProviderBase
  - Enable management of input selectable from ComboBox also in the multi-instance case
refs 1841

- Enable binding a AnnotationValueProvider to multiple model elements in a single <annotationViewPart /> statement
refs 1841

refs 2119

- EStructuralFeatureValueProviderBase: Gracefully handle the case that instance keys returned by getInstanceKeys() are not backed by a EStructuralFeatureValue
- Concrete value providers may use this to implement an overlay of e.g. derived/computed annotations onto a concrete IAnnotationSpecification that consists of one or more EAttributes
refs 1841

- Ensure that independently of the currently selected model element type, annotations are shown for the entire sub-model below the IProjectRoot element above that currently selected model element. E.g., in the LA, show annotations for Channels in case a Component is currently selected
refs 1841

- Fix typo in GUI label
- Formatting of comments
refs 1841

- SingleEStructuralFeatureValueProvider -> EStructuralFeatureValueProvider (can optionally handle multiple EStructuralFeatures contained in a specification)

- TODO: Mixing the edit support (ComboBox, Text) and the EStructuralFeature type (enum vs. other primitive data types) is not possible)
refs 1841

  - Enable selection of values for non-enum attributes from a combo box. The following options are available:
    - Fix set of values
    - Dynamically managed set of values. The user may either choose from the existing values for a given annotation type, or enter a new one. Deleting existing choices is also supported.
  
- AnnotationViewPartBase: Also watch specifications in order to ensure update of admissible choices (see code for detailed comments)

- GenericAnnotationView: Set viewer input before construction of columns in order to enable aggregation of admissible values
refs 1841

refs 1841

refs 1841

- Add comparator that sorts rows according to hierarchy level. Elements within one hierarchy level are sorted by name.
refs 1841

- Ignore update requests for elements that are not hook to a top-level element,
e.g. SET events that are fired when a component is removed (before the actual REMOVE event).
- Otherwise, the AnnotationValueService would create an NPE during the preparation of the context via KernelModelElementUtils.runAsCommand()
refs 1841

refs 1841

refs 1841

- Optimize drawing speed by disabling the redraw while the new set of columns is beeing created

- Ensure that "Create" columns for dynamic multi-instance annotations are right to the corresponding instances.
- Simplify column handling. Merge updateSingleInstanceAnnotationColumns() / updateMultiInstanceAnnotationColumns() into update()
refs 1841

 - allowsMultipleAnnotationInstances() -> allowsDynamicAnnotationInstances()
 - add getInstanceKeys()
- MultiInstanceValueProviderBase -> DynamicInstanceValueProviderBase
- Concrete IValueProviders may now either support the dynamic creation of instances (using the EMap based implementation provided by DynamicInstanceValueProviderBase)
- Alternatively, IValueProviders may statically support a number of "views" onto an annotation by returning the supported instance keys in getInstanceKeys() and implementing the required case distinction in get/setAnnotationValue() and createEditingSupport()
refs 1841

 - Change return type of getValue() to T
 - This allows for more type safe implementation of the underlying calculations
 - The former abstract base class DerivedAnnotationBase used Object as a return type for getValue() to due an EMF code generation bug for generics if the base class is located in a different .ecore file than the concrete class. For interfaces, this bug is not triggered.
  
refs 1841

Introduce "derived" annotation, i.e. based on calculations instead of explicit annotations / model contents can be implemented

- DerivedAnnotationBase meta-model element, with getValue() EOperation, and a extensive documentation.
- Corresponding DerivedAnnotationValueProviderBase, implementing a read-only, text-view of the calculation result
- To implement the above, move handling of annotation EClass & factory to ValueProviderBase

refs 1841

- Fix NPE in case a filter actually strikes

 - renamings of model elements (e.g., in the properties view)
 - addition of new instances of multi-instance annotations

-> Use originator of the notification, and not the new value to trigger the update
refs 1841

refs 1841

- Move column label provider displaying the model element names in the first column to a dedicated class ElementNameLabelProvider
- Introduce IAnnotationViewPart

- Ensure and document that all output of TextEditingSupport.getValue() is converted to a non-null String. This is required because this value will be consumed in TextCellEditor.doSetValue() which expects such input

- Apply <underlying EMF Factory>.createFromString() to all String input in order to ensure conversion for input received e.g. from TextCellEditors on all code paths

refs 1841

- Install {@link Adapter} to watch for the addition or removal of model elements to/from elements visible in this {@link AnnotationViewPartBase} (to trigger according updates).
- Ensure that all annotations for all offspring of the currently selected are shown in the view
- AnnotationViewPartBase no longer maintains a protected attribute with the list of current annotation entries, but triggers the abstract update(Collection<AnnotationEntry>) method at the right occasions (to be implemented by concrete views).
- Possible improvement in GenericAnnotationView: efficient implementation of update(Collection<AnnotationEntry>) (instead of complete redraw).
refs 1841

- Extend IAnnotationValueProvider with getter/setter methods to access individual instances of a multi-instance IAnnotatedSpecification

- The storage of the instances is based on an EMap<String, V> in the corresponding IAnnotatedSpecification.

- See MultiInstanceAnnotationValueProviderBase for documentation how to create the corresponding meta-model for the annotation types, and of course use it as a basis for specific multi-instance value providers.

- Merge SingleAttributeValueProviderBase and SingleEDataValueProviderBase to SingleEStructuralFeatureValueProviderBase, and generalize it to work on EStructuralFeatures. This is required to support both EAttributes and "contained" EReferences as annotation storage in the meta-model.

- With the above change, cleanup and extend the instantiation of annotation attributes / contained references to EClasses.

- Extend the GenericAnnotationView to enable instantiation of multi-instance annoations.
refs 1841

- IAnnotationValueProvider
  - allowsMultipleValues() -> allowsMultipleAnnotationInstances()
  - createEditingSupport()
     - Remove unused parameter
     - Method is unconditionally used to construct the editing support. Defaults
       are set in base classes implementing IAnnotationValueProvider.
  - remove getFixedValues(): SingleEnumAttributeValueProviderBase() creates the required ComboBoxEditingSupport
  
- IAnnotationValueProvider base classes:
  - ValueProviderBase: Empty implementation of interface
  - SingleAttributeValueProviderBase: IAnnotationValueProvider manages a single attribute of a given specification class. Probably nearly all static annotations will be based on this.
  - SingleEDataTypeAttributeValueProvider: primitive data types (e.g., int, double), and potentially many other data types managed by EMF
  - SingleEnumAttributeValueProvider: Provides ComboBoxEditingSupport based on enum declaration in Ecore meta-model.

- Further fixes:
  - Make combo box in ComboBoxEditionSupport non-editable
  - Prevent NPE in TextEditingSupport.getValue()
  
- Use new base classes in test annotation classes
refs 1841

- Provide generic abstract base classes:
  - ValueProviderBase -> for generic annotated specifications
  - SinglePrimitiveAttributeValueProviderBase, for annotated specifications whose storage is implemented by a single primitive attribute (Double, Integer, String, etc.)

- Introduce sub packages for annotation framework (see org.fortiss.tooling.base.ui.annotation -> package.html for documentation)
- Standardize class names

 - add setAnnotationValue(String value, T specification) in addition to setAnnotationValue(V value, T specification) variant
 - This enables to use the String-based AnnotationEditingSupportStandard for non-String annotations.
 - Concrete AnnotationValueProviders must implement this method and convert the String representation of the input to the storage format provided by the respective annotation class (e.g., for Double, just by using the Double(String) constructor)
 - The current implementation  has been tested with String, Double, enum and multiple value String annotations

- TODO:
  - Cleanup of IAnnotationValueProvider
  - Base class hierarchy for common concrete annotation value providers
  - multiple value annotation support in GenericAnnotationView

refs 2093