Community
Participate
Working Groups
Created attachment 111259 [details] Patch to fix this issue Build ID: M20080221-1800 Steps To Reproduce: See attached JUnit-tests More information: There are different kinds of typeconformance-checks in the implementation of at least v1.1.x and v1.2.x. This affects the usage of user-defined EDataTypes which are similar to OCLs PrimitiveTypes. These differences are striking, if you use an EDatatype with name "OwnInteger" and instanceClass java.lang.Integer in the usermodel: - In the variable-section of let-expressions and the accumulator-definition of iterate-expressions, TypeUtil#typeCompare(..) is used while validation. This causes "let i:OwnInteger=5 in i" fail because IntegerLiteral is no valid OwnInteger. - For looking up an operation which matches the given arguments, UMLReflectionImpl#getOCLTypeFor(...) is used. This causes, that an operation defined as foo(OwnInteger) matches the operation foo(Integer). The call foo(5) matches, too. - If an operation is called on an user type, it is converted to an OCL standard type before retrieving the available operations (UMLReflectionImpl#getOCLTypeFor(...)
Created attachment 111262 [details] JUnit-tests to demonstrate this issue
I would like to add my vote for this bug but I don't get an option to do that. Any idea why?
(In reply to comment #2) > I would like to add my vote for this bug but I don't get an option to do that. > Any idea why? Perhaps you have exhausted your vote quota (Bugzilla can limit votes on a per-component and a per-user basis). I'll have a look at Stefan's patches in this milestone (nicely rounded out with JUnit tests, even, thanks!), and may consider it for the 1.2.3 maintenance, too. At about 1K, it looks pretty low-risk.
Thanks Christan. That would be appreciated. Incidentally I have only used 2 out 10 votes. The 'vote for this bug' does show up on other bugs (at least ones I raised)
(In reply to comment #4) > Thanks Christan. That would be appreciated. > > Incidentally I have only used 2 out 10 votes. The 'vote for this bug' does show > up on other bugs (at least ones I raised) I checked in the My Foundation portal, and the per-user vote limit for the MDT product is set to 0, which would prevent anybody from voting on any MDT bug. I have to suppose that this is a mistake, and I'll ask about it on our developer list.
(In reply to comment #4) > > Incidentally I have only used 2 out 10 votes. The 'vote for this bug' does show > up on other bugs (at least ones I raised) Voting is now enabled for the MDT product.
Created attachment 114804 [details] Combined patch Reworked Stefan's attachments as a single patch, to apply in both the 1.2.3 and 1.3 branches and include attribution of the contribution.
Patch committed to HEAD. Targeting 1.2.3 release.
Patch committed to 1.2.3 branch. Thanks, Stefan!
Closing after over 18 months in resolved state.
