Community
Participate
Working Groups
Papyrus should support the notion of Language, especially for some specific DSML which require some specific tooling or configuration (e.g. PapyrusRT and SysML change the standard UML Semantics and are not simple extensions). The language should be serialized into the *.di model when required
New Gerrit change created: https://git.eclipse.org/r/48469 WARNING: this patchset contains 2407 new lines of code and may require a Contribution Questionnaire (CQ) if the author is not a committer on the project. Please see:https://wiki.eclipse.org/Project_Management_Infrastructure/Creating_A_Contribution_Questionnaire
Extracted from gerrit: CWD: As discussed on the call today with Camille, rather than introduce a new model and content into the *.di resource, it would be nice to be able to rely on the presence of a Profile to indicate the language, especially because a single package may have content defined in multiple languages, and different packages in a single model may have content defined in different languages. ProfileApplications really do define a meaningful scope. However, I understand also that there is a problem of needing to be able to recognize that a language is employed in a resource before loading that resource. To this end, I think we can use the general-purpose model indexing system provided by the WorkspaceModelindex API. It makes it quite straight-forward to build an index of, for example, profile applications across the workspace that doesn't require loading resources into a ResourceSet. The API encourages a non-blocking asynchronous style of queries (indexing runs as a background job), but for an editor needing to know about languages before loading resources, there is a synchronous query API also). It is possible that the DecoratorModelIndex already indexes normal "internalized" profile applications as well as "externalized" applications, but I think not. In any case, it is in the wrong plug-in for the ModelSet and its Models to access it. But I think it could easily be extended to index internalized profile applications also and wired up as a data-provider to some API in a core plug-in for access by the editor. Language support will need to account for externalized profile applications anyways ... WDYT? P.S. I heard from a source that, for example, UML-RT "language" implies a custom implementation of the UMLPackage with different behaviour. How is that supposed to work for mixed-language models? Where some packages are UML-RT and some are not ... CL: UML-RT is this kind of profile which does not simply "annotates" an existing UML Model, but is actually "required" (Un-applying the profile changes the semantics of the Model). However it does play well with annotation profiles, for platform/language-specific code generation. But the UML-RT Profile/Stereotypes need to remain applied. In this specific case, it should "almost" be forbidden to externalize the UML-RT Profile. Unapplying the profile is a major refactoring with major impacts on the Model (From a semantics point of view) Same thing for SysML; it defines a new language rather than an extension of UML
It would be indeed nice to have a service for model language(s) in Papyrus, that could rely for the implementation on the various model indexers. This service could be ask at any moment to get the language for the given model. The only concerns I have is with the model wizard. as soon as we create a UML-RT model, we would like to have the UML specific API used, and I am not sure the WorkspaceModelIndexer is able to work nicely in these conditions. The second concern is for the integration of EMF Compare, which should also be aware of the language, with models that may not be in the workspace (EGit / logical model integration). That's why I added Philip and Laurent in the discussion. At runtime, applying or unapplying the UML-RT profile on a opened model should not be possible, or at least, this should trigger a refactoring action on the model, with at the end a hot-swap of the EFactory or a "restart" of the model set to take into account the new EFactory. Same applies of course to SysML. This is specifically true for UML-RT language, as there should be also an implementation language defined for the model, with specific model library import.
> The only concerns I have is with the model wizard. as soon as we create a UML-RT model, we would like to have the UML specific API used, and I am not sure the WorkspaceModelIndexer is able to work nicely in these conditions. I'm not sure that's really required. The factory doesn't have any impact on serialization, so we can use the standard one to create the model, save it, then start an editor with the proper service and factory (Which is what happens today; the ModelSet/ServicesRegistry used by the wizard is disposed after we press "finish", and a new one is started by the editor when it starts) Wizards have always worked with a subset of the ServicesRegistry, so this shouldn't be an issue. I'm however more concerned about EMFCompare, which (AFAIK) doesn't use the Papyrus ModelSet. Instead, I believe it uses a standard ResourceSet, initialized with Papyrus Load/Save options. Maybe this has changed now? Most Papyrus components rely on the ModelSet and should be OK (e.g. Model Search), but we may need to double-check them as well.
(In reply to Remi Schnekenburger from comment #3) > It would be indeed nice to have a service for model language(s) in Papyrus, > that could rely for the implementation on the various model indexers. > This service could be ask at any moment to get the language for the given > model. The only concerns I have is with the model wizard. as soon as we > create a UML-RT model, we would like to have the UML specific API used, and > I am not sure the WorkspaceModelIndexer is able to work nicely in these It should not be a problem. The new model resource is created by copying a template. Once the workspace IFiles are created, the indexer will learn of them and schedule an indexing run on them. The editor will synchronize with that indexing operation as it would any other before loading these new resources. > conditions. The second concern is for the integration of EMF Compare, which > should also be aware of the language, with models that may not be in the > workspace (EGit / logical model integration). That's why I added Philip and > Laurent in the discussion. That is more interesting, and actually speaks to my serious concern about the whole custom-factory strategy. If UML-RT is changing the semantics (behaviour) of the UML metamodel, then it is no longer UML and the UML2 Java interface specifications are violated. Applications that do not know about UML-RT semantics cannot operate on these models as though they are UML models and, IMHO, that is fundamentally broken. It's not just EMF Compare, but any application or plug-in that provides UML services will break on UML-RT models.
(In reply to Christian W. Damus from comment #5) > That is more interesting, and actually speaks to my serious concern about > the whole custom-factory strategy. If UML-RT is changing the semantics > (behaviour) of the UML metamodel, then it is no longer UML and the UML2 Java > interface specifications are violated. Applications that do not know about > UML-RT semantics cannot operate on these models as though they are UML > models and, IMHO, that is fundamentally broken. > > It's not just EMF Compare, but any application or plug-in that provides UML > services will break on UML-RT models. I think we need to be a bit more clear about what specializations of the UML meta-model we are talking about, before drawing too many conclusions about how things will break. As I see it there are two sets of specializations of the UML meta-model needed: 1) Operations that are used for defining constraints, e.g. isConsistentWith() and validateParameterMatch(), needs to be "tweaked" to be able to cope with how redefinition is allowed to be made in UML-RT, to avoid too strict constraints to generate incorrect errors/warnings when validating a UML-RT model. 2) Changing the type of a port and property to be derived, to make it possible to leave the redefining port/property untyped, i.e. the type is in that case derived from the redefined port/property. It could of course be discussed how severe it will be that some constraints will be violated and that some port/properties will be untyped, when a UML-RT model will be openeded in context where the specialized UML meta-model is not being used. The whole area of how state-machine inheritance and how redefinition is handled, is specific to the UML-RT DSML anyway, including the layout inheritance, that applications and plugins operating on a UML-RT model needs to know about UML-RT anyway.
New Gerrit change created: https://git.eclipse.org/r/49152
Gerrit change https://git.eclipse.org/r/49152 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=d2dc2fd8777bbd50aa0ac10845b156d64be5695d
I think this is resolved now by the introduction of the Language Service, right? I would resolve the bug, but it's not assigned to me. :-)
I've abandoned the Gerrit draft related to the initial proposition, and Gerrit 49152 is merged I close this task
