Hi,
Regarding objections, I have a hard time knowing who would object to the removal. I have always assumed that you, Ernesto, it the one with the best insight into why we even have these dependencies to the Designer plugins... :)
Indeed, but I just wanted to make sure that there are no uses elsewhere, considering the discussion on consistency at today's synchronization meeting and specially since I've been away for a couple of weeks, so I'm just getting up to speed with the new build.
Just to get your confirmation. So we are talking about only leaving dependencies to the following two plugins:
org.eclipse.papyrus.designer.languages.common.base
org.eclipse.papyrus.designer.languages.cpp.library
Correct.
Makes sense. I just pushed a gerrit (with you, Celine and Christian as reviewers), but I didn't add these plugins to either feature. I can do that as part of this Gerrit, or should I do that separately?
Either the code-generator feature (org.eclipse.papyrusrt.codegen-feature.feature.group) or the core C++ feature (org.eclipse.papyrusrt.umlrt.cpp.feature.feature.group). It feels rather natural that the C++ feature at least have the dependency to the org.eclipse.papyrus.designer.languages.cpp.library since the C++ default language descriptor is the one that brings in and needs the C++ primitive types library. The other "common.base" plugin I don't really know what it is all about.
The "common.base" is used for incremental generation: we detect changes in the model using some classes from that common.base plugin. Perhaps there is another way of implementing it that does not depend on Designer, but I do not know. This was code written a long time ago by Toby, which is no longer active in the project.
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev