Community
Participate
Working Groups
It's odd to use e.g. OCL to initialize string attribute with a fixed literal (e.g. MindMap example uses OCL expression "'includes'"). And even ECore's EReference.setContainment(true/false) might benefit from simple boolean literals. For such cases, better approach would be as-is value, or literal, that would get assigned without any further involvement of expressions/evaluators. Need to add another language to ValueExpression to support literal values, templates should get updated to pass value as is (e.g. false or "includes"). Besides, no extra expressions/factories (AbstractExpression, OCLExpression, OCLFactory) should get generated if no OCL or similar expression is in use.
ValueExpressions that are used from FeatureSequenceInitializers can be of LITERAL kind now, which effectively injects expression body right into appropriate feature (so that ECore Diagram EReference's initialization looks like 'eRef.setContainment(true)' instead of all the 'OCLFactory.getExpression("true",...).evaluate(eRef)') GMF Codegen updated to respect actual expression kinds (based on providers present in the model), and doesn't generate AbstractExpression if there are no uses of it. Note, this is sort of a change people out there might be affected with, if they relied on the class being generated always. Tests: ElementInitializerTest#testLiteralElementInitializers()
[target cleanup] 2.2 M1 was the original target milestone for this bug
[GMF Restructure] Bug 319140 : product GMF and component Models - Mapping was the original product and component for this bug
