Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
OCL/New and Noteworthy/Helios
Eclipse OCL New and Noteworthy items for the Helios release.
The Helios MDT-OCL release will be 3.0.0 rather than 2.0.0, since the Galileo plug-ins contained a mix of 1.3.0 and 2.0.0 versions. The 2.0.0 versions were mandated by a major version change in UML2.
Contents
MDT-OCL 3.0.0 API Changes
As a major release's change, MDT-OCL 3.0.0 is expected to break API. You can check all API changes under discussion here.
One of the main goal to achieve in the MDT-OCL 3.0.0 release is migrating all grammars and parsing infrastructure so that they are based on the last version of LPG 2, whose runtime is sensibly improved and will allow to introduce a fancy textual OCL editor which will help the user to create OCL expressions. An OCL extending language will need to change their grammars/parsing infrastructure if they want to extend OCL in 3.0.0. A changes log and some advice for OCL extenders have been registered here.
A migration guide is under construction.
MDT-OCL 3.0.0 Capabilities
The bug 299344 provides information about how the capabilities will be dealt in the Helios release. In order to comply with this requirement, we provide documentation about how to define a proper Activity definition for MDT-OCL 3.0.0 which may be used by third parties to configure their product capabilities:
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin>
<extension
point="org.eclipse.ui.activities">
<!-- Activity definition -->
<activity
description="%_UI_capabilities.activity.description"
id="org.eclipse.ocl.activity"
name="%_UI_capabilities.activity.name">
</activity>
<!-- Activity pattern bindings -->
<!-- Contributions to Examples -->
<activityPatternBinding
activityId="org.eclipse.ocl.activity"
pattern="org\.eclipse\.ocl\.examples.*">
</activityPatternBinding>
</extension>
</plugin>
Note: The code above just provides the Activity definition. A proper capabilities configuration should provide a "category" and a "categoryActivityBinding". You also have a complete capabilities configuration in the "org.eclipse.ocl.capabilities" plugin from CVS.
Milestone 2
invalid/Invalid/OclInvalid resolved
The OMG OCL 2.0 specification is very unclear as to the relative status of invalid objects and types. The tentative OCL 2.1 specification is little better.
The problem is easily understood by contrasting invalid with the uncontentious null: null is the null object that is the sole instance of the OclVoid which is the sole instance of VoidType meta-class.
Section 8.2 tends to suggest that: OclInvalid is the invalid object that is the sole instance of Invalid which is the sole instance of the InvalidType meta-class. This is what MDT-OCL 1.3.0 realises.
Section 11.2.4 and 11.2.5 are much more consistent in preferring: invalid is the invalid object that is the sole instance of OclInvalid which is the sole instance of the InvalidType meta-class. This is the revised implementation for MDT-OCL 3.0.0.
Beware. This change has a significant API incompatibility; the OCLStandardLibrary methods getOclInvalid and getInvalid have interchanged semantics. All calls to getOclInvalid and getInvalid should be reviewed, since errors may be silent. Concrete syntax changes are less likely to cause trouble.
Comments parsed
Bugzilla: 286724
Comments are now parsed as LPG Token Adjuncts enabling tools that want access to comments to find them.
static features supported for the UML binding
Bugzilla: 285633
The proposed OCL enhancement to allow a 'static' keyword prefix to a 'def' constraint is implemented for the UML binding, unless ParsingOptions.SUPPORT_STATIC_FEATURES is set false in the Environment, in which case an error is generated.
Ecore does not support static EStructuralFeatures and so use of 'static' gives an error when the ECore binding is used.
setStatic, isConstraint and isPackage are added to the UMLReflection API.
CST inelegancies removed
Bugzilla: 287993
@pre is now represented by a non-null rather than null IsMarkedPreCS object. Previously this was coded by a true/false value of the IsMarkedPreCS.isPre field. Analyzer code explicitly handling IsMarkedPreCS objects must be revised to handle the null object logic.
InvCS, DefCS, InitCS and DerCS are now maintained in a PropertyContextCS.constraints or ClassifierContextDecl.constraints array. The reverse lexical order linked list daisy chain is no longer supported.
PathNameCS.simpleNames and StateExpCS.simpleNames replace PathNameCS.sequenceOfNames and StateExpCS.sequenceOfNames. This changes a List<String> to a List<SimpleNameCS> which avoids loss of IToken context.
Milestone 3
This milestone is pending.
OCL 2.1 Precedence changes
Bugzillas: 288040
xor now has higher precedence than or which is higher than and.
A ParsingOptions.WARN_OF_XOR_OR_AND_PRECEDENCE_CHANGE may be set to give a warning when OCL 2.1 has a different meaning to MDT/OCL 1.3's left-associative interpretation of OCL 2.0.
OCL 2.1 Grammar alignment
The grammar has been substantially revised to align with the likely OCL 2.1 specification.
This may impact on implementers of derived languages, who may wish to consult the MDT/OCL/MDT-OCL 3.0.0 Migration Guide.
The spelling of many production names is changed, mostly in just the first letter.
The term factoring of some productions has changed.
As a result problems with if and let are resolved.
It is also temporarily possible to use non-reserved words in many contexts where the specification currently allows them. An OMG issue will be raised to make self, true, Bag etc reserved words.
The Essential OCL grammar is now completely separable so that re-users can avoid any grammar baggage from Complete OCL. Re-users may re-use EssentialOCL.g, EssentialOCLLexer.g and EssentialOCLKWLexer.g.
Milestone 4
OCL 1.4.0 compatibility release abandoned.
EMF EModelElement change
EMF's EModelElement no longer reports EObject operations in eAllOperations(), so OCL expressions invoked on meta-models that extend EModelElement and invoke methods such as eContainer(), eContents() or eGet() will fail.
Visibility of these methods was not compliant with the OCL specification, so this EMF change will not be hidden.
However the ParsingOptions.IMPLICIT_ROOT_CLASS facility previously used to activate EObject methods in non-EModelElement extending meta-models provides a solution.
Initialize your environment with the following ParsingOption declaration prior to parsing.
ParsingOptions.setOption(ocl.getEnvironment(),
ParsingOptions.implicitRootClass(ocl.getEnvironment()),
EcorePackage.Literals.EOBJECT);
Methods such as oclContainer(), oclContents() and oclGet() are planned for MDT/OCL 4.0.0.
Milestone 5
LPG v2.0.17 adoption
In M5, the parsing infrastructure has changed so that now it relies on LPG v2.0.17. Some reasons for accomplishing this change are the follwing:
- We tend to ship an OCLEditor as an example which uses IMP, which uses LPGv2. So, since LPGv2 will be needed by the example it should be good that the parser uses the same runtime, and we could then forget the old one.
- Technically, LPGv2.x runtime has been refactored improving its design, including more interfaces, etc which should also be exploited by MDT-OCL. As long as possible, MDT-OCL 3.0.0 will take advantage from the LPG's templates and API changes.
- Technically, LPGv1.x runtime has some deficiences relating performance and memory usage. For instance, an identified issue related to the backtracking parser which used an IntTuple action = new IntTuple(1 << 20) to stack parser actions. In Lpg v2.x an improved dinamic array is used instead, which shouldn't use so amount of memory: private IntSegmentedTuple action = new IntSegmentedTuple(10, 1024)
Some bugzillas related to this new LPG v2.0.17 runtime adoption, which have been introduced in M5:
- LPG v2.0.17 into Orbit. - 298128
- Modification to support IMP and exploit LPG v2.0.17. - 242153
- Exploit LPG v2.0.17 runtime. Reintroduce official LPG templates. - 299396
- Refactoring MDT-OCL grammars to remove the use of deprecated macros - 300534
Note: If you are extending MDT-OCL grammars and/or parsers you may want to check the following migration guide
Milestone 6
OCLinEcore
OCLinEcore support added allowing dynamic validation of Ecore models against OCL in meta-models 191689 291361 291365
Milestone 7
All OCL Examples renamed from org.eclipse.emf.ocl.examples... to org.eclipse.ocl.examples...
Four Xtext editor examples have been added. The decision to redevelop these editors using Xtext, rather than migrate the IMP editors from M2M/QVTd 289761 was occasioned by IP issues and the very model-aligned Xtext capabilities that arose at EclipseCon after M6. The editors are therefore very new. Expect significant improvements as they and Xtext mature.
CompleteOCL editor
This editor supports development of a textual *.ocl document that complements a *.ecore meta-model using the syntax of Section 12 of the OMG specification. Additionally an import statement is supported.
Use New Project->Examples->Royal and Loyal Example for an example project.
OCLinEcore editor
This editor supports development of OCL within an Ecore model using a textual syntax that covers all Ecore and OCL concepts. See OCLinEcore.
If the editor is invoked on a *.ecore model, it is saved back as *.ecore, unless SaveAs OCLinEcore is used from the Document entry on the Outline menu to save as *.oclinecore, which persists the textual format.
EssentialOCL editor
This editor supports development of a textual *.essentialocl document that comprises a single OCL expression. It is unlikely that this editor would be used standalone. It is anticipated that it will be useful as a pop-up within other tools.
OCLstdlib editor
This editor supports development of the OCL standard library definition, that is used by the Xtext editors, and which in OCL 4.0.0 will form the extensible definition of all analysis and evaluation. The default OCL standard library may be found in the model folder of the essentialocl editor.
M2M/QVTd migration
OCL Model Registry Example added allowing use of Ecore models without genmodeling 289759.
SR1
Eclipse OCL New and Noteworthy items for the Helios 3.0.1 SR1 release.
OCL
Ecore
- 322159 Diagnose and workaround genmodel without Operation Reflection.
Examples
OCLinEcore editor
- 318119 Save no longer flashes XMI.
- 320689 Enum and DataType now conform to OclAny so that e.g. oclIsInvalid is no longer undefined.
- 321171 Reference opposite is now resolvable when the type is qualified.
- 321493 Unicode characters supported in annotations.
- 321518 Multi-line annotations supported.
- 321903 Supertype is now resolvable when qualified.
- 322675 OCLinEcore menu items now localized to OCLinEcore.
- 322886 CompleteOCL genmodel registration now findable.
SR2
Eclipse OCL New and Noteworthy items for the Helios 3.0.2 SR1 release.
OCL
- 330489 Fix content of singleton CollectionRange.
Ecore
- 329980 Use @nooverride to clarify API