Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 156361

Summary: EMF 2.3/J2SE 5.0 support
Product: [Modeling] OCL Reporter: Christian Damus <give.a.damus>
Component: CoreAssignee: Christian Damus <give.a.damus>
Status: CLOSED FIXED QA Contact:
Severity: enhancement    
Priority: P3 Keywords: api, plan
Version: 1.0.0   
Target Milestone: M5   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description Christian Damus CLA 2006-09-06 10:43:13 EDT 
EMF's 3.0 version will include J2SE 5 support (see bug 79768).  OCL should support EMF 3.0, which may include regenerating the OCL metamodel using EMF 3.0 to match EMF's J2SE 5.0-enabled capabilities.
Comment 1 Christian Damus CLA 2006-11-15 13:54:38 EST 
Updated the heading, given that the next EMF release number has been fixed at 2.3.
Comment 2 Christian Damus CLA 2006-11-17 11:58:57 EST 
Est.: 1.5w
Comment 3 Christian Damus CLA 2007-01-26 16:46:32 EST 
Committed the adoption of EMF 2.3 to OCL's new home in the Modeling CVS repository:

  /cvsroot/modeling/org.eclipse.mdt.ocl.eclipse.ocl

This feature includes: 

  - defining a new generic Abstract Syntax model for OCL, using the new capability of 
    modeling generic types in Ecore (after the Java fashion).  This removes the parser's 
    dependency on the Ecore metamodel 
  - refactoring the parser, validator, and interpreter to work with this new generic AST 
  - enhancing the Environment API to provide the metamodel reflection required by the parser 
    that previously was implemented using the Ecore API 

The new OCL API is provided by a new org.eclipse.ocl feature.  This feature includes: 

   - a new org.eclipse.ocl plug-in containing the parser/interpreter core and generic AST model 
   - a new org.eclipse.ocl.ecore plug-in containg the Ecore binding (environment implementation) 

The existing org.eclipse.emf.ocl feature now includes org.eclipse.ocl.  The existing API of the 
org.eclipse.emf.ocl plug-in is retained for backward compatibility.  The internals, however, are 
refactored to delegate the parsing of OCL constraints to the new API.  This ensures that future 
fixes in the grammar definition or other aspects of the parser are not missed by the compatibility 
API.  This compatibility layer translates the parsed ASTs from the 1.1 model to the 1.0 for 
consumption by legacy clients and also provides a new utility for converting 1.0 ASTs to 
the 1.1 model (in case some client somewhere had managed to successfully persist ASTs in 
the 1.0 model).
Comment 4 Nick Boldt CLA 2008-01-28 16:36:45 EST 
Move to verified as per bug 206558.
Comment 5 Ed Willink CLA 2011-05-27 02:39:32 EDT 
Closing after over a year in verified state.
Comment 6 Ed Willink CLA 2011-05-27 02:41:30 EDT 
Closing after over a year in verified state.