Community
Participate
Working Groups
We know that several features related to interpreted expression do not work very well when Sirius has to guess which user metamodels should be considered (see for example AQL expressions validation/interpretation). In general, everything is much easier for Sirius and much more stable (and less confusing) for end-users if the metamodels are properly registered in the VSMs. We should make it mandatory (as much as possible) for all the metamodels referenced in a VSM to be registered. This includes at least all the domain classes and all the type literals in all the interpreted expressions in the VSM. Given only the metamodels explicitly registered in the VSM, we should be able to resolve all of these types. If the VSM is inside a plug-in project, we should also make sure the project has dependencies (directly or indirectly) on plug-ins which provide said metamodels).
Additional use case: . Metamodel plugins in the workspace (and non-deployed) . VSM plugin in the workspace . We currently register the platform:/resource uri of the ecore file. -> Once deployed, Sirius will not be able to retrieve it. We might need something like an element with two attribute: the nsUri and some optional location (to be able to compute and retrieve the platform:/resource uri to ease the completion, validation and other VSM editor features).
Created attachment 257858 [details] Ecore Editor ui to load EPackage since EMF 2.9
(In reply to Maxime Porhel from comment #1) > Additional use case: > . Metamodel plugins in the workspace (and non-deployed) > . VSM plugin in the workspace > . We currently register the platform:/resource uri of the ecore file. > -> Once deployed, Sirius will not be able to retrieve it. > > We might need something like an element with two attribute: the nsUri and > some optional location (to be able to compute and retrieve the > platform:/resource uri to ease the completion, validation and other VSM > editor features). I think the right answer is simpler than that. We should rely on the target-platform support EMF core brings with org.eclipse.emf.ecore.plugin.EcorePlugin.computePlatformURIMap(true) (since EMF 2.9) and update the UI accordingly based on what has been done in EMF itself (see attachment). We could even consider not even proposing an alternative solution to the "Browse Target Platform Packages" button as any other solution might work "by chance" but is quite unreliable.
New Gerrit change created: https://git.eclipse.org/r/66188
The MM_registration_in_VSM_spec.textile specification has been added in previous gerrit which covers many aspects about using declared MM only. It covers validation, completion and run-time and also UI aspects. The scope of this ticket is about validation described below: only RepresentationDescription meta-models in the scope of validation. That bug handle part of the validation aspects ensuring that meta-models are correctly declared and also that Domain class is part of the declared Meta-modes Below is an extract of the MM_registration_in_VSM_spec.textile that corresponds to what is done in the scopr of this ticket *RepresentationDescription metamodels* The validation on odesign should provides an error in the following cases: * if there is no registered meta-models on RepresentationDescription * if registered meta-models are not among VSP dependencies and its transitive dependencies. This rule is only if the odesign is owned by a VSP. (We consider that a VSP is a plugin which contains an extension to org.eclipse.sirius.componentization) * when the RepresentationDescription does not register the MM used for : [...] ** a non null Domain Class
New Gerrit change created: https://git.eclipse.org/r/67215
New Gerrit change created: https://git.eclipse.org/r/67214
As part of this ticket, or maybe bug #487999, we should add the same "Browse Target Platform Packages" as present in recent versions of EMF, see org.eclipse.emf.ecore.presentation.EcoreActionBarContributor.ExtendedLoadResourceDialog.
Moving this top-level ticket to 4.1. More disucssion is needed around this whole issue of "which metamodels are visible/registered at any point in time/in the code". For 4.0 we'll only do two things: * Add a VSM validation rule that raises a warning if any RepresentationDescription defined inside lacks explicit metamodels. * Add an "Add from Target Platform" button along with the exising "from Registry", "from workspace" and "from filesystem" in RepresentationDescriptionMetamodelPropertySectionSpec. I'll create two separate tickets for these specific issues.
Warning: the metamodel should not be referenced through the current URI. For example if I add the metamodel > <metamodel href="http://www.eclipse.org/sirius/sample/basicfamily#/"/> (like in https://git.eclipse.org/r/73413) for the "Persons diagram" diagram of the Basic Famly sample, and then open the VSM (with the MM not deployed, ie MM and VSP are in the same workspace), I have the exception: java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(Unknown Source) at org.eclipse.sirius.editor.properties.sections.description.representationdescription.RepresentationDescriptionMetamodelPropertySectionSpec.refresh(RepresentationDescriptionMetamodelPropertySectionSpec.java:225) at org.eclipse.ui.views.properties.tabbed.TabContents$6.run(TabContents.java:217) ... when I clicked on the representation. The above gerrit was abandonned for this reason to avoid that end-user will be confronted to this problem with the basic family example.
See: . https://git.eclipse.org/r/#/c/67215 . https://git.eclipse.org/r/#/c/72930 Those patch sets were initially proposed as draft for Bug 493330 which haas been resolved for Sirius 4.0.0. I move them here for the moment but they might later require the creation of specific bugzilla regarding the status of this one.
