refs 2255

refs 2255

refs 2255

refs 2255

Bugfix: Use annotation instance key in setValue(). This is already done in getValue() / getLabel()

- Add Id, version, and ConQAT tags to XML files

* Mainly documentation cleanup
* Remove some commented out code

org.fortiss.tooling.kernel.internal.storage.eclipse.ModelContext:
org.fortiss.tooling.kernel.utils.EMFResourceUtils:
 - Resolve B.19 issue (numbering scheme as of Aug. 14, <https://af3-developer.fortiss.org/projects/autofocus3/wiki/Check-list_for_Code_Reviews/56>) "Use static imports"
refs 2255

- Annotations are now instantiated in ElementCompositorService. Hence, this migration will not be required in the future.
refs 2208

refs 2140

refs 2055

refs 2055

- Ensure that the annotation view is updated when switching between multiple projects by fixing a bug in the EAdapter registration
refs 2236

- Fix last commit: Actually allow one connection from a IHierarchicElement (node) to a free IConnector
refs 2233

- Prevent multiple fan-in for IHierarchicElement -> IConnector connections (was erroneously enabled in some cases)
- If this is desired, concrete compositors should override canConnectInterally()
refs 2233

refs 2208

refs 1491,2203

- Instead, ensure that DiagramEditorBase has the focus when a child edit part is added or removed
- This works around #2207 and also the same part of #1491 as with the old workaround
- Summing up:
   - Undo/redo of operations on the model only works if either the NavigatorViewPart or a DiagramEditorBase has the focus
   - This makes sense if the active view provides editable items itself (e.g., the GenericAnnotationView) *and* provides undo/redo (currently not the case for GenericAnnotationView).
   - For other (read-only) view (e.g., Model Markers), this behavior is confusing for the user
refs 2207,1491

- Fix addition of spurious undo/redo command by ensuring that annotations are instantiated from HierarchicElementCompositorBase.compose()
- Derived compositors that override compose() must ensure that call their parent classes' implementation
refs 2208

- Move annotation value service, annotation value provider base classes and annotation extension point to org.foritss.tooling.base
- Remove createEditingSupport() from IAnnotationValueProviderBase and move functionality to org.fortiss.tooling.base.ui.annotation.editingsupport.EditingSupportFactory instead
- Rename extension point to org.fortiss.tooling.base.annotation.

Example binding:

<extension point="org.fortiss.tooling.base.annotation">
  <annotation binding="org.fortiss.af3.timing.annotation.valueprovider.CIValueProvider">
     <modelElementClass modelElementClass="org.fortiss.af3.component.model.Component"/>
  </annotation>
</extension
- Adapt all known users of annotation framework to new structure
- The change is a preparation to fix #2208, i.e. to put the instantiation of a model element and its annotations into a single undo/redo command
refs 2208

- 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.