Community
Participate
Working Groups
To reproduce the issue create a new properties view, define a new page named 'Override' which extends the Ecore page defined in the Ecore tools properties view. In the General tab set the Label expression to 'Override'. Ecore tools must be deployed in the current environment. The expected result is that instead of the 'Ecore' tab in properties view provided by Ecore tools available when you click on an ecore element, you would see an 'Override' page which contains exactly the same thing than the original page. The issue is that overriding a page from a deployed plugin is ignored. After having a look to the code on debug, I found that the cross referencer does not return the 'overrides' reference in case of a deployed plugin. Have a look to the /org.eclipse.sirius.properties.core/src/org/eclipse/sirius/properties/core/api/OverridesProvider.java#getOverrideDescriptions method line 58: crossReferencer.getInverseReferences(eObject, true).stream() .filter(setting -> "overrides".equals(setting.getEStructuralFeature().getName())) //$NON-NLS-1$ .map(Setting::getEObject) .filter(AbstractOverrideDescription.class::isInstance) .map(AbstractOverrideDescription.class::cast) .forEach(descriptions::add);
Created attachment 269733 [details] Sample project to try (unsuccessfuly) to reproduce the issue I can't reproduce the problem. The steps I followed: 1. Make sure Ecore Tools is either installed or present in you workspace. 2. Import the attached VSP. It defines an empty Viewpoint "Bugzilla-519566" and 2 pages descriptions: - the first one *extends* the default Ecore Tools page (ecore_page) and is named "Extension" - the second one *override* the default Ecore Tools page and is named "Override". It also extends ecore_page to get default content. 3. Launch a runtime. 4. Create a new Modeling Project, and enable the "Design" viewpoint from Ecore Tools on creation (not Bugzilla-519566 for now). 5. Add a new ecore model and create a class diagram on it: the normal Ecore Tools properties pages are available. 6. Enable Bugzilla-519566, and select an element from the diagram. The "Ecore" tab is replaced by an equivalent "Override" page, and an additional "Extension" page is also present (with the same content). These correspond to the extension & override defined in the sample VSP, and work as expected (at least in this scenario).
Waiting for more specific reproduction steps. Will close as WORKSFORME if none can be found.
Created attachment 270011 [details] Sample project to reproduce the issue Actually the bug depends on how the "local" VSM references the one where the extended/overridden elements are defined. * If the reference uses "platform:plugin" URLs, the bug is present. * If the reference is done through a viewpoint: URI (e.g. viewpoint:/org.eclipse.emf.ecoretools.design/Design in the attached example), the bug is not present and both extension and override work.
For reference, the original forum message about this issue: https://www.eclipse.org/forums/index.php/mv/msg/1087387/1767798/#msg_1767798
It took me a while to be sure I understand what's happening, as there are several possible combinations, some of which trigger the "bug" and some don't. In the end, I'm almost tempted to close as INVALID, as it works "as designed", but clearly our UI (in the VSM editor especially) makes it too easy to trigger this behavior. Here's what happens: 1. The "extending" VSM (the one which defines the page override) is authored in the workspace. To reference the extended VSM (e.g. Ecore Tools), which is part of an installed plug-in, the most obvious/natural solution is to: - Import the Ecore Tools plug-in in the workspace. - In the VSM editor, "Load resource..." and choose "Browse workspace..." to select the ecore.odesign we just imported. - Then we can define our page extensions/override, and refer to elements from Ecore Tools. - When saving this, the extending VSM refers to ecore.odesign with a relative "../.." URI. 2. To test the result, the specifier creates a new Modeling Project in the same workspace, adds an Ecore model to it, and enables both the Ecore Tools "Design" viewpoint and a viewpoint from the extending VSM. Here's the trap: there are *2* Ecore Tools "Design" viewpoints available in this setup, and Sirius proposes both. One is taken from the installed plug-ins, and one is taken from the project imported in the workspace. If the user enables the one from the workspace, everything works fine. If the user enables the one from the plug-in, the bug appears. When the bug occurs, the Sirius session has 2 viewpoints enabled: * One from platform:/resource/the.extending.vsm/pages.odesign (VSM1) * One from platform:/plugin/org.eclipse.ecoretools.design/description/ecore.odesign (VSM2) As mentioned above, VSM1 has been serialised with relative references to the Ecore Tools one, so VSM1 also loads platform:/resource/org.eclipse.ecoretools.design/description/ecore.odesign (VSM3) to resolve its references, but that is *not* the VSM considered as enabled by Sirius. When we create properties pages for, e.g. an EPackage, we'll look at pages definitions from VSM1 and VSM2. - If VSM1 has elements that *extends* Ecore Tools pages, everything seems to work, because we're getting the definitions from VSM3, which (confusingly in this case) are equivalent to the ones in VMS2. - If VSM1 has elements that *override* Ecore Tools pages however, we won't find them: we'll ask the cross-referencer for elements that refer to the "ecore_page" from VSM2, but there are none: VSM1 elements refer to the "ecore_page" from VSM3, hence the behavior observed. Note that the bug does not occur in normal usage when all the modelers are deployed. In that case, there is no dual versions of the same viewpoints to confuse the user, and the relative URI between two plug-ins resolve to the correct version. So to conclude: * For Sirius 5.0.2, and probably 5.1.0 too, we'll simply complete the documentation and mention this "gotcha". * I'll open a separate ticket for a later version (maybe 6.0, with no guarantee) to fix this more thoroughly. One part could be to improve the VSM editor to make it easy to load (and refer to) deployed plug-ins, and the other to serialize inter-VSM references in a more flexible way (we already have viewpoint:/ URIs, but they're not as well supported as they could/should be).
New Gerrit change created: https://git.eclipse.org/r/104712
Gerrit change https://git.eclipse.org/r/104712 was merged to [v5.0.x]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=bf46808af145d943439cd6c8fb4fa4665e15740f
Fixed by bf46808af145d943439cd6c8fb4fa4665e15740f. See bug #522035 for the followup.
Verified on 5.0.2rc2.
Available in Sirius 5.0.2.
