Community
Participate
Working Groups
Various constraints need to be updated to both the structure and state machines profiles as per document version of Jun 11, 2015. Also, the outdated model library needs to be removed from the profile
New Gerrit change created: https://git.eclipse.org/r/50000 WARNING: this patchset contains 2906 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
Please consider to fix Bug 464387 at the same as this proposed update to the UML-RT profile, to avoid having to make too many updates to the profile.
(In reply to Peter Cigéhn from comment #2) > Please consider to fix Bug 464387 at the same as this proposed update to the > UML-RT profile, to avoid having to make too many updates to the profile. Just a reminder.
Uploaded (and accepted) new patch to gerrit. It also includes a re-generated plugin.xml in the valudation plugin. Since the build is working again, it can be tested with the nightly build
There's one thing I forgot to ask: the new version of the profile from Bran deletes the constraint "A capsule class cannot have nested classifiers". Was this intentional or something added after Bran's commit? (I should have asked this before accepting the gerrit change, sorry).
As Peter pointed out in 464387, some constraints IDs are inconsistent with the name/purpose of the constraint. The ID entry in the validation rule is optional. If left empty, the ID is generated automatically. In case of the rule that Peter mentioned, it will become: UMLRealTime.Capsule.All operations of a capsule are guarded This is a rather long ID, but this is not a tooling problem. Should we remove all user defined IDs to avoid the risk of future name inconsistencies? I've create a new gerrit, I realized that I forgot to remove the obsolete RTservice library. I will add the patch for it, once we agree whether we remove user defined IDs.
(In reply to Ansgar Radermacher from comment #5) > There's one thing I forgot to ask: the new version of the profile from Bran > deletes the constraint "A capsule class cannot have nested classifiers". Was > this intentional or something added after Bran's commit? This should have been intentional since the constraint was too strict. As can be seen in Bug 469677, the new child menu for UML-RT shall provide the possibility of creating passive classes and enumerations as nested classifiers of a capsule.
(In reply to Ansgar Radermacher from comment #6) > As Peter pointed out in 464387, some constraints IDs are inconsistent with > the name/purpose of the constraint. > > The ID entry in the validation rule is optional. If left empty, the ID is > generated automatically. In case of the rule that Peter mentioned, it will > become: > > UMLRealTime.Capsule.All operations of a capsule are guarded > > This is a rather long ID, but this is not a tooling problem. > Should we remove all user defined IDs to avoid the risk of future name > inconsistencies? > > I've create a new gerrit, I realized that I forgot to remove the obsolete > RTservice library. I will add the patch for it, once we agree whether we > remove user defined IDs. As I commented in Bug 464387 Comment 5, I am not fully sure that leaving the id empty and let it be automatically generated really solves the issue of keeping things consistent between the actual constraint definition (name and OCL expression) with the properties of the <<ValidationRule>> stereotype, e.g. you still need to keep the 'message' property in sync (and potentially also 'description' if and when we want to utilize that for conveying even more information to the end-users). First I would like to see a well defined process of how the profile is updated and clear responsibilities between who is doing what in the update process.
I'm currently updating the profile and also removing the message attribute whenever it is identical to the name (which is currently always the case, except in case of errors: I also found "A relay port must be a service port" which had an inconsistent message). When there actually is a message attribute (that is not identical to the name), I propose to put it into the diagram. This will greatly simplify the task of validating. (In reply to Peter Cigéhn from comment #8) > .. > > As I commented in Bug 464387 Comment 5, I am not fully sure that leaving the > id empty and let it be automatically generated really solves the issue of > keeping things consistent between the actual constraint definition (name and > OCL expression) with the properties of the <<ValidationRule>> stereotype, > e.g. you still need to keep the 'message' property in sync (and potentially > also 'description' if and when we want to utilize that for conveying even > more information to the end-users). First I would like to see a well defined > process of how the profile is updated and clear responsibilities between who > is doing what in the update process.
(In reply to Ansgar Radermacher from comment #9) > I'm currently updating the profile and also removing the message attribute > whenever it is identical to the name (which is currently always the case, > except in case of errors: I also found "A relay port must be a service port" > which had an inconsistent message). > > When there actually is a message attribute (that is not identical to the > name), I propose to put it into the diagram. This will greatly simplify the > task of validating. > Do you have any current examples (apart from the case with "A relay port must be a service port" which as you say have a completely faulty message set) where you have a difference and you plan on keeping 'message' explicitly set in the stereotype? I just have a feeling that we currently should not have any cases where message intentionally should differ from the name of the constraint. So I guess that you mean that only i the future, whenever we find that the message should be more descriptive than just the name of the constraint, we should explicitly set a 'message'. Right?
I did not discover any other examples of a diverging message. Yes, I was referring to an eventual need in the future. It can make sense in some cases (e.g. constraint name = only 1 xy authorised, message = there are >1 of xy) - but we should put the message in the diagram for those cases. Right now, I have removed all user defined messages and IDs, the change is in gerrit https://git.eclipse.org/r/#/c/56705/ (In reply to Peter Cigéhn from comment #10) > ... > Do you have any current examples (apart from the case with "A relay port > must be a service port" which as you say have a completely faulty message > set) where you have a difference and you plan on keeping 'message' > explicitly set in the stereotype? > > I just have a feeling that we currently should not have any cases where > message intentionally should differ from the name of the constraint. So I > guess that you mean that only i the future, whenever we find that the > message should be more descriptive than just the name of the constraint, we > should explicitly set a 'message'. Right?
Someone volunteers to look at the profile in gerrit? https://git.eclipse.org/r/#/c/56705/ I can also push the changes without further verification (i.e. you verify by using the nightly builds afterwards)
(In reply to Ansgar Radermacher from comment #12) > Someone volunteers to look at the profile in gerrit? > https://git.eclipse.org/r/#/c/56705/ > > I can also push the changes without further verification (i.e. you verify by > using the nightly builds afterwards) I guess it really should be Bran that takes a look, especially if you have updated the diagrams since I assume that Bran uses the diagrams in the profile document itself. I do know that Bran is planning on making some updates to the profile document (and the profile also) soon including support for FinalState for passive state machines and adding some constraints related to multiplicity for capsule parts (and I guess also ports). I myself do not have an environment setup for Gerrit so I have a hard time checking it (and only looking via the Web-interface is a bit of a pain with the models).
I did a try checking via the Web-interface, and from what I could see there is still one constraint that has message and id set, "Exclusion can only be applied to some model elements". I also saw that message and id is set on the stereotype with an empty string. But I guess that the tooling does not bother if the property is completely unset (from an EMF perspective) or if the property is set to an empty string? Hard to check other stuff via the Web-interface.
(In reply to Peter Cigéhn from comment #14) > I did a try checking via the Web-interface, and from what I could see there > is still one constraint that has message and id set, "Exclusion can only be > applied to some model elements". > > I also saw that message and id is set on the stereotype with an empty > string. But I guess that the tooling does not bother if the property is > completely unset (from an EMF perspective) or if the property is set to an > empty string? > > Hard to check other stuff via the Web-interface. I overlooked that, it's corrected with the latest patch. Yes, does not matter whether empty of not defined at all.
I checked patch 5, and the message has been cleared for that constraint, but the id is still set, 'exclusionOnlyOnUmlRt'.
(In reply to Peter Cigéhn from comment #16) > I checked patch 5, and the message has been cleared for that constraint, but > the id is still set, 'exclusionOnlyOnUmlRt'. In new patch set (yes, it's good to read your message completely before submitting).
(In reply to Ansgar Radermacher from comment #17) > In new patch set (yes, it's good to read your message completely before > submitting). Can't see any patch set 6 yet. Not sure if you meant that you had pushed a new patch set, or if you planned to make it later. Or if something went wrong...
The profile is now submitted to master (commit 4dc78a599186cc920a07121997927f4feffaf36d).
I've checked the latest build and the new version of the profile looks okay. See Bug 464387 Comment 14 for some additional comments related to the changes of the message property of the <<ValidationRule>> stereotype. I suggest that we put this Bugzilla into verified.
(In reply to Peter Cigéhn from comment #20) > I've checked the latest build and the new version of the profile looks okay. > See Bug 464387 Comment 14 for some additional comments related to the > changes of the message property of the <<ValidationRule>> stereotype. Yes, I could image to have an additional attribute "defaultMessage" in the DSMLValidation stereotype with the enumeration options "constraint name", "<constraint name> is violated", "custom (message attribute)", but this is a new tooling bug. > I suggest that we put this Bugzilla into verified. From a process viewpoint, that is Bran's or your task
(In reply to Ansgar Radermacher from comment #21) > (In reply to Peter Cigéhn from comment #20) > > I suggest that we put this Bugzilla into verified. > > From a process viewpoint, that is Bran's or your task Yes, I know. I do this on all Bugzillas that I have access to. But for this Bugzilla I cannot update it, so then I guess it has to be Bran that makes that change.
I just saw that there were some tests that started to fail due to this being merged: https://hudson.eclipse.org/papyrus-rt/job/Papyrus-RT-Master-All/165/ Something wrong with the tests, or do we have an actual regression?
Since I do not have access to the latest build I am happy to take Peter's and Ansgar's word for when the issue should be moved to Verfied status - provided that I am the one who should be doing that. Just send me an e-mail and I will do it (to hell with the formal bureaucratic process).
(In reply to Peter Cigéhn from comment #23) > I just saw that there were some tests that started to fail due to this being > merged: > > https://hudson.eclipse.org/papyrus-rt/job/Papyrus-RT-Master-All/165/ > > Something wrong with the tests, or do we have an actual regression? Yes, there was something wrong with the test, verified ok with build https://hudson.eclipse.org/papyrus-rt/job/Papyrus-RT-Master-All/166/ While I verified that the validation runs fine for the model that is used for the validation test, I did not actually run the test. The test code selected a rule by using its ID which had obviously changed. ID has been changed in test with commit 4dc78a599186cc920a07121997927f4feffaf36d.
Based on Ansgar's feedback
