| Re: [papyrus-rt-dev] Papyrus Designer dependencies in Oomph setups |
Hi,We have to many communication channels (developer list, Gerrit changes, Bugsillas) and too many parallell discussions right now... :)Comments inline belowOn 18 October 2016 at 18:09, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:On Tue, Oct 18, 2016 at 11:52 AM Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:Hi,Well, the only objection to changing to much at this point in time would be that we are are really late in 0.8 release cycle. The idea of moving the idea of moving the dependencies of these plugins to other existing features is probably something that we should do post-0.8. I just realized that I get confused about why we even need these explicit dependencies anyway, now seeing the proposed Gerrit change where I see that for the common.base plugin we already have a dependency from an existing plugin (in the code-generator) to this plugin. Then why do we even need an explicit dependency to it?I don't know why these are on the rcp. I didn't add them there. And I think you are right, there shouldn't be an explicit need to add them there.The reason why there were added to the RCP was simply that we were trying to align the contents of the Oomph tester-setup and the contents of the RCP. Since the RCP is feature based, we could not add the dependencies directly to the product configuration, but had to add them as dependencies to the RCP feature as a "work around" to ensure the consistency with what the Oomph tester setup was bringing in.
Starting to see how these plugins actually are being referenced by other plugin and other features, I would like to ask the question: Why was the dependencies to these plugins even added to the Oomph tester setup from the beginning? I think that is where all this confusion about these Designer plugins starts. If I recall it correctly, it was you that added them Ernesto (originally we brought in features from Designer which brought in too much UI elements, but this was changed to these four plugins). Actually Céline did the same "mistake" in one iteration of the RCP build and also brought in some Designer features (which in its turn brought in these plugins). But this causes UI bloat and then we reverted to this solution of adding them as dependencies from the RCP feature itself.
What goes around comes around... :)Anyway, I suggest that we continue that discussion post-0.8 and decide what to do with the dependencies to the remaining two plugins. I have a strong feeling that the common.base dependency belongs to the code-generator feature and the cpp.library dependency belongs to the C++ language feature.I think you are right. Currently, the library is listed as a dependency, but not included in the codegen feature. It is also listed as a dependency but not included in the umlrt.cpp feature.
/Peter CigéhnOn 18 October 2016 at 17:43, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:Hi,On Tue, Oct 18, 2016 at 11:30 AM Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote: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.baseorg.eclipse.papyrus.designer.languages.cpp.libraryCorrect.If these two are the only one lefts, then I assume that we could have a choice of adding these dependencies to two of our existing features (as proposed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=505416#c63)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./Peter CigéhnOn 18 October 2016 at 17:21, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:Right. I'll push a gerrit to check, but there are two sets of changes:1) to the setup models (tester and developer)2) to the manifest of oeprt.codegen.cppMy question is whether you are ok with each of these.I'll add you as a reviewer.On Tue, Oct 18, 2016 at 11:16 AM Céline JANSSENS <celine.janssens@xxxxxxxxxxx> wrote:Hi Ernesto,
Be careful, because sometimes, deleting a plugin from a Manifest doesn’t seem to raise any issue, but when building the plugin, it can break some dependencies.
You can at least test it through Gerrit ;)
Regards
Céline
De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de Ernesto Posse
Envoyé : mardi 18 octobre 2016 17:11
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Papyrus Designer dependencies in Oomph setups
We had the oep.designer.languages.common.profile plugin in the oeprt.codegen.cpp plugin. It's in the manifest. I do not remember why it was there. I just tried removing it and there doesn't seem to be a problem, so we can remove that as well.
So are there any objections to these changes?
On Tue, Oct 18, 2016 at 11:07 AM Céline JANSSENS <celine.janssens@xxxxxxxxxxx> wrote:
Yes. The question is: Do we use the oep.designer.languages.common.profile feature in Papyrus-RT ?
If not, let it implicit
If Yes, we should add it explicitly.
Céline
De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de Peter Cigéhn
Envoyé : mardi 18 octobre 2016 17:03
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Papyrus Designer dependencies in Oomph setups
Hi,
If the oep.designer.languages.common.profile gets added implicitly, then that is something that we cannot do anything about I guess. At least as long as we don't add the dependency to it explicitly ourselves, I am fine with that.
/Peter Cigéhn
On 18 October 2016 at 16:59, Céline JANSSENS <celine.janssens@xxxxxxxxxxx> wrote:
Hi Peter,
In RCP this is what I did. I reference dependencies of the following plugins on the rcp feature (as I don’t know exactly which feature requires those plugins)
· org.eclipse.papyrus.designer.languages.common.base
· org.eclipse.papyrus.designer.languages.cpp.library