Community
Participate
Working Groups
The current UML2 example plugins org.eclipse.sphinx.examples.uml2.* use the Form editor with the original UML item property descriptors. Consequently, scoping does not work for setting cross references in the properties view, e.g. all compatible model elements from all Sphinx-loaded models are calculated and offered as reference targets. These 3 bundles are currently needed to enable Sphinx resource scoping in the UML2 Form Editor: - org.eclipse.sphing.examples.emf.ecore.edit - org.eclipse.sphing.examples.uml2.edit - org.eclipse.sphing.examples.uml2.ide.ui The goal is to replace the superclass 'ItemProviderAdapter' in all UML item providers with the Sphinx-specific 'ExtendedItemProviderAdapter' class, and to replace the superclass 'ItemPropertyDescriptor' in all UML item provider descriptors with the Sphinx-specific 'ExtendedItemPropertyDescriptor' class. Unfortunately, the UML edit plugin 'org.eclipse.uml2.uml.edit' refers to EMF ecore item providers as superclasses, so we must actually change the EMF ecore item provider adapter and descriptor superclasses. By the way, using the genmodels with an adjusted superclass for the item providers to generate separate Sphinx-specific edit plugins is not sufficient because both edit bundles contain manual adjustments; this is why we have to copy them. IMPORTANT: Copying the two edit plugins means that they are EMF/UML version-specific! As soon as there is a new release for EMF or UML, the customized copies of the edit plugins must be updated, too! (This is why I don't provide a patch here, because it would only match one single version.) 1. Create bundle org.eclipse.sphing.examples.emf.ecore.edit as a copy of org.eclipse.emf.ecore.edit with the following adjustments: - Change bundle name and ID to: org.eclipse.sphing.examples.emf.ecore.edit - Restrict dependency to org.eclipse.emf.ecore to the current specific version - Remove item provider adapter registration (delete plugin.xml) - Change superclass of the following item providers to 'ExtendedItemProviderAdapter': - EModelElementItemProvider - EObjectItemProvider - EStringToStringMapEntryItemProvider - Change superclass of the following item provider descriptor to 'ExtendedItemProviderDescriptor: - EModelElementItemProvider.ItemPropertyDescriptorWithUniqueChoiceOfValueLabels 2. Create bundle org.eclipse.sphing.examples.uml2.edit as a copy of org.eclipse.uml2.uml.edit with the following adjustments: - Change bundle name and ID to: org.eclipse.sphing.examples.uml2.edit - Restrict dependency to org.eclipse.uml2.uml to the current specific version - Remove item provider adaper registration (delete plugin.xml) - Replace plugin dependency to 'org.eclipse.emf.ecore' with 'org.eclipse.sphinx.examples.emf.ecore.edit' - Change superclass of UMLItemPropertyDescriptor to 'ExtendedItemPropertyDescriptor' 3. Bundle org.eclipse.sphing.examples.uml2.ide.ui must be adjusted/extended: - Replace plugin dependency to 'org.eclipse.uml2.uml.edit' with 'org.eclipse.sphinx.examples.uml2.edit' - Add class 'UML2ComposedItemProviderAdapterFactory extends ComposedAdapterFactory' as singleton and add these adapter factories in the constructor: - UMLItemProviderAdapterFactory (from bundle org.eclipse.sphinx.examples.uml2.edit) - UMLResourceItemProviderAdapterFactory (from bundle org.eclipse.sphinx.examples.uml2.edit) - The following classes have been created/adjusted to implement 'getCustomAdapterFactory' and (if necessary) replaced in the respective extensions in plugin.xml: - UML2EditorActionBarContributor - UML2FormEditor - UML2AdvancedPropertySection - UML2ExplorerContentProvider - UML2ExplorerLabelProvider Maybe there is a more elegant way of doing that?! At the moment, the effort for maintaining multiple versions of the edit plugin duplicates prevents these changes to be included in the Sphinx UML2 extensions.
Thank you for submitting this issue and the detailed description of the tentative solution. To have a more satisfying solution that avoids duplication of the Ecore and UML2 edit plug-ins and the maintenance of the same in different versions, we would probably need a modification on EMF side. The point is that we want to customize the behavior of the ItemPropertyDescriptor#getChoicesOfValues() method. To avoid that this must be done by either overriding all item provider classes for all UML2 model elements or changing the super classes in the item provider/item property descriptor class hierarchy as explained above, we would need some kind of delegation mechanism on ItemPropertyDescriptor#getChoicesOfValues(). It could work similar as that in org.eclipse.emf.edit.command.AbstractOverrideableCommand, where the command execution is delegated to an overrideCommand if available. In the same sense, I could imagine to have some sort of ChoicesOfValuesProvider delegate that gets invoked by the ItemPropertyDescriptor if available and can be implemented as appropriate by adopters. When no such ChoicesOfValuesProvider is available, the ItemPropertyDescriptor just executes the existing behavior. To avoid that the custom ChoicesOfValuesProvider needs to be hooked in by (again) overriding each and every item provider, we would also need an extension point through which this can be achieved centrally. Similar extension points already exist at EMF model level, where EDataType conversions, EOperation invocations, queries, derived EStructuralFeatures and validations can be delegated from the generated EMF model code to an application-defined plug-in.
Stephan, is the prerequisite for your intended fix already backed by an EMF change request?
(In reply to Alexander Nyßen from comment #2) > Stephan, is the prerequisite for your intended fix already backed by an EMF > change request? No, not yet. Do you want me to create such one?
Well, if you plan to ever resolve this, it would probably be a good idea. I don't think EMF will introduce such a feature by accident...
(In reply to Alexander Nyßen from comment #4) > Well, if you plan to ever resolve this, it would probably be a good idea. I > don't think EMF will introduce such a feature by accident... The intention of my question was rather to get an idea of the level of importance of this issue. Just a matter of making sure that there is a real interest in getting this fixed before starting to invest actual effort.
(In reply to Stephan Eberle from comment #5) > (In reply to Alexander Nyßen from comment #4) > > Well, if you plan to ever resolve this, it would probably be a good idea. I > > don't think EMF will introduce such a feature by accident... > > The intention of my question was rather to get an idea of the level of > importance of this issue. Just a matter of making sure that there is a real > interest in getting this fixed before starting to invest actual effort. It's no blocker for us. Nevertheless it seems to be a bug within Sphinx. As its currently UNCONFIRMED my intention was to enforce some triaging on this.
Closed stale issue before migration
