- Avoid case distinction in GenericAnnotationView that handles construction of EditingSupport for boolean annotations
- This fixes the bug that the EditingSupport was only created correctly for derived annoations (#2225)
- Add TODO to delegate construction of label provider to annotation value provider, too (#2226)
refs 2225,2226

refs 1491

- Fix crash in some annotation value providers during undo/redo by checking if annotation specifications are registered with a model element
refs 2204

refs 2133

- Document that getAnnotation(IModelElement modelElement, Class<T> clazz) wraps the model access into a command
refs 2199,1841

- Ensure that that AnnotationsUtils.getAnnotation(IModelElement modelElement, Class<T> clazz)  actually wraps the extraction / creation of an annotation into a command
- DAGExtractionWithoutDeployment: use this variant
refs 2199,1841

- If the annotations view is not visible (i.e., not opened at all, or not the active tab), create and raise the properties view
- Otherwise, just create the properties view, but do not raise it (the annotation view acts as a replacement for many properties)
refs 2133

- Change view ID to "org.fortiss.tooling.base.ui.annotationView" and define a Java String constant for it
refs 2133,1841

- Eliminate superfluous override of performRequest() because of the inheritance relation: ConnectorEditPartBase -> PositionedEditPartBase -> GraphicalEditPartBase
- GraphicalEditPartBase provides the desired functionality to raise the properties view, and PositionedEditPartBase does not override this behavior
refs 2133

- No functional change
refs 2133

refs 2189,1841

refs 2189,1841

refs 1841

- Install EAdapter for top level element of current project (instead of switching it the currently active root element (e.g., component architecture)).
- This ensures that annotation views are updated also on changes of models that currently do not have the focus (i.e. programmatic changes of models that are currently not shown in the diagram view)
refs 1841

- Display model element ID in tooltip (in addition to model element name). This is useful to identify selection targets for annotations of type EReference where the editor also displays the ID in order to distinguish elements with the same name.
refs 1841

- Add isAvailableObject() method that can be overridden by value providers in order to filter the set of available elements

LabelValueMapping: Use this filter
refs 1841

refs 1841

- TextEditingSupport / ElementEditingSupportBase: Unset value if users enters the empty string
refs 1841

Modify the DerivedAnnotationValueProvider (org.fortiss.tooling.base.ui), such that the editability of the annotation editing support mirrors the behavior of the derived annotation.

- Remove support for multiple selections of values since it is not supported by EMF which enforces that the lists used to implement features with multiplicity > 1 are unique:

<https://www.eclipse.org/forums/index.php?t=msg&th=133621&goto=417016&#msg_417016>

refs 1841

refs 1841

refs 1841

- Support to select an element more than once (enabled by default). In order to disable this feature, use the map-based constructor of EStructuralFeatureValueProviderBase and construct the EStructuralFeature accordingly.
- Fix update of Ok button when deselecting all elements (fire second event to work around bug in DualList base class)
refs 1841

refs 1841

refs 1841

refs 1841

- Do not cache LabelValueMapping since {@link IDerivedAnnotation}s support that the {@link {EStructuralFeature} of their return value is changed at runtime
refs 1841

refs 1841

refs 1841

refs 1841

- Do not expose createComboBoxLabelValueMapping()
- Instead, provide getLabel()
refs 1841

- Implement MultiSelectionEditing support that currently supports the selection of multiple values for EReferences (based on OPAL's DualList)
- Rename ComboBoxLabelValue mapping -> LabelValueMapping
- Update AnnotationViewPartBase also on ADD_MANY / REMOVE_MANY events
refs 1841

- Add private getAnnotationValueProvider() method
refs 1841

  - Remove getEStructuralFeatureOf()
  - Expose DEFAULT_KEY (from AnnotationValueProviderBase)
  - createEditingSupport(): Pass current specification

- AnnotationEntry:
  - Remove getSpecificationElementFeature()
  - Add getSpecification(). TODO: Use this method internally in AnnotationEntry
  
- EStructuralFeatureDescriptor
  - getEStructuralFeature(): Pass current specification
  
- Base on the above, no longer base logic to compute the currently active EStructuralFeature for IDerivedAnnotiations on a temporary EStructuralFeatureDescriptor
refs 1841

- Adjust all annotations that inherited from IDerivedAnnotation to use the new DerivedAnnotationBase class
- EOperation cleanup
- Move getValue() from org.fortiss.tooling.base.utils.AnnotationUtils to org.fortiss.tooling.base.model.base.impl.DerivedAnnotationBaseStaticImpl

refs 2171

- This should fix the related crashes that contained multiple objects with the same name
refs 1841

- Add AnnotationInstantiationMigrationProvider that augments loaded models with annotations that have been added to the AF3 installation after the creation of the model.
- Note that:
  - It is still required to use AnnotationUtils.getAnnotation() to obtain (and potentially instantiate) an annotation. This is because annotations are only instantiated for newly added model elements if the annotation view is visible.
  - IMigrationProviders that convert old attribute values into annotations cannot rely on the fact that the annotation instance already exists (since the execution order of the IMigrationProviders is not defined). Hence, the need to use AnnotationUtils.getAnnotation(modelElement, clazz, false) to obtain (and potentially instantiate) an annotation (without wrapping the model access into a command, see #2010).
refs 1841

- Prevent nested calls of selectionChanged() which could trigger a refresh of the table before all column label providers / editing support has been initialized
refs 1841

  - Add getAnnotation(IModelElement, Class<T> clazz, boolean)  variant that lets the caller control if the potential instantiation of an annotation should be wrapped into a command.
  - The original getAnnotation(IModelElement, Class<T> clazz) variant still exists and still defaults to wrapping the instantiation into a command
- AnalysisMigrationProvider / SafetySpecToAnnotationMigrationProvider: Use the new method to prevent the creation of a command in order to prevent the use of the IPersistencyService during the migration (workaround for the annotation-related aspect of #2010)
refs 2010,2172