Community
Participate
Working Groups
Many errors in code generation are due to model errors. Many of these result in errors while translating to the new intermediate meta-model. The translator should catch these errors and provide better error reporting, pointing to the relevant UML element that caused the problem. A patch has been merged which catches many errors but not all. It catches several of the most common errors, like missing types in features (parameters, ports, parts, etc.) When the error occurs, it produces an exception with some detailed information: - A message - The fully qualified name of the UML Element under consideration - The name of the feature within the element which is causing a problem - The expected UML type for the feature in question - The expected type returned by the translation to the intermediate meta-model - The actual UML type for the feature - The actual translated type in the new meta-model More errors should be catched, not only by the translator, but in later stages.
Changed component to 'codegen' and marked as accepted.
Does not gate the June release 1.0 Papyrus-RT release
Such error reporting would help in supporting the product. Need evaluation of effort required Moving to 0.9.0 for assessment.
New Gerrit change created: https://git.eclipse.org/r/98962
Gerrit change https://git.eclipse.org/r/98962 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=37ccc743e46cad16342cc57ff3d5884e111669b3
New Gerrit change created: https://git.eclipse.org/r/99274
New Gerrit change created: https://git.eclipse.org/r/99276
Gerrit change https://git.eclipse.org/r/99274 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=5078727641f2b651a5825f3cdcc1ea2141c02f55
New Gerrit change created: https://git.eclipse.org/r/101303
Gerrit change https://git.eclipse.org/r/101303 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=f5415c8359bb014909f3b80f1e9d6e9ba71ad1a5
The change with the latest improvements is merged, but should we marked it as "resolved"? The bug is a bit too open-ended. We could move it to future, to add further improvements later, or we could mark it as resolved and future improvements would be addressed by explicit bugs.
(In reply to Ernesto Posse from comment #11) > The change with the latest improvements is merged, but should we marked it > as "resolved"? The bug is a bit too open-ended. We could move it to future, > to add further improvements later, or we could mark it as resolved and > future improvements would be addressed by explicit bugs. As you say, these kind of "open-ended" bugs is hard to mark as resolve and could continue to stay open forever. I suggest to mark it as resolved fixed as "good enough" for 1.0. Further improvements should then be tracked by separate, more explicit bugs. One such future improvement is of course the integration with the problems view and the double-click support to navigate to the offending model element. In my view, the most important is that we have a "framework" in place for reporting any kind of error/warning from the code-generator, where it should be very easy (a few lines of code) to add a check and reporting of a new error/warning (which is then tracked with an explicit bug). I hope/assume that this bug has ensured that such a "framework" is in place, and if so then it can be considered to be resolved.
(In reply to Peter Cigehn from comment #12) > (In reply to Ernesto Posse from comment #11) > > The change with the latest improvements is merged, but should we marked it > > as "resolved"? The bug is a bit too open-ended. We could move it to future, > > to add further improvements later, or we could mark it as resolved and > > future improvements would be addressed by explicit bugs. > > As you say, these kind of "open-ended" bugs is hard to mark as resolve and > could continue to stay open forever. I suggest to mark it as resolved fixed > as "good enough" for 1.0. Further improvements should then be tracked by > separate, more explicit bugs. One such future improvement is of course the > integration with the problems view and the double-click support to navigate > to the offending model element. > > In my view, the most important is that we have a "framework" in place for > reporting any kind of error/warning from the code-generator, where it should > be very easy (a few lines of code) to add a check and reporting of a new > error/warning (which is then tracked with an explicit bug). I hope/assume > that this bug has ensured that such a "framework" is in place, and if so > then it can be considered to be resolved. I concur with Peter's statement. I think we should move this but to closure and create a "Future" bug to address new bugs, starting with Peter's suggestion for "Integration with the problems view and the double-click support to navigate to the offending model element".
(In reply to Peter Cigehn from comment #12) > (In reply to Ernesto Posse from comment #11) > > The change with the latest improvements is merged, but should we marked it > > as "resolved"? The bug is a bit too open-ended. We could move it to future, > > to add further improvements later, or we could mark it as resolved and > > future improvements would be addressed by explicit bugs. > > As you say, these kind of "open-ended" bugs is hard to mark as resolve and > could continue to stay open forever. I suggest to mark it as resolved fixed > as "good enough" for 1.0. Further improvements should then be tracked by > separate, more explicit bugs. One such future improvement is of course the > integration with the problems view and the double-click support to navigate > to the offending model element. > > In my view, the most important is that we have a "framework" in place for > reporting any kind of error/warning from the code-generator, where it should > be very easy (a few lines of code) to add a check and reporting of a new > error/warning (which is then tracked with an explicit bug). I hope/assume > that this bug has ensured that such a "framework" is in place, and if so > then it can be considered to be resolved. The "framework" put in place is essentially this: in the code generator, we have validation performed in different places: 1) on the UML model, before translating to XtUML-RT 2) on the UML model, during the translation to XtUML-RT 3) on the XtUML-RT model, after the translation The bulk of the validation is done in steps 1 and 2. Step 1 is the natural place to put new validation rules. This corresponds more closely with the semantic validation of the language. Most of the validation done in step 2 pertains translation: it consists of checking that whenever a UML Element's feature is being translated, the feature is not null (unless it is allowed), that the feature's content has the expected type, and the translated feature has the expected type. Steps 2 and 3 will eventually disappear when we remove the XtUML-RT model altogether. Nevertheless, validation in step 3 was added manly with the idea of supporting code generation directly from XtUML-RT (e.g. starting with a textual model) or possibly from other models translated into XtUML-RT, like XtUML, as it was originally designed for that purpose. I just want to state for the record something that I've said before: codegen validation is not a "catch-all" validation, and in particular, there are problems that it cannot resolve. For example if a UML Property intended to be a capsule part doesn't have the CapsulePart stereotype. In such cases, the translator cannot guess the user's intentions, so we cannot issue either a warning or an error (because perhaps the user did intend to make it into a normal Property) but the later phases may result in errors that may seem unrelated. This sort or problem should not occur if we have models which are "correct by construction", but there are several scenarios which may lead to such errors: 1) there could be bugs in the tooling that do not make the model correct-by-construction 2) there could be bugs introduced by new versions of the tooling (I've seen this happening all the time with diagrams; I would expect that the models are a bit more "solid", but I'm not 100% sure that's always the case) 3) the model could be corrupted somehow 4) the model may have been produced, not by our tooling, but by something else, e.g. some user customization of the tooling, or some programmatically generated model. So in summary, codegen validation should not be considered a replacement to proper validation.
Verified.
Closing.
(In reply to Ernesto Posse from comment #14) > So in summary, codegen validation should not be considered a replacement to > proper validation. Yes, and validations are tracked separately with Bug 492833.
