[mdt-ocl.dev] 3.1, 3.2, etc Progress

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

I'm making good progress, but of course not as much as I hoped.

I now have the OCL runtime pivot model defined as a UML merge, with MWE 
scripts automating the merge, alphabeticising and genmodeling.

I have the OCL Standard Library Xtext editor maintaining the OCL 
standard library as a Pivot Model definition.

I have an Acceleo transformation so that the standard OCL 'Standard' 
Library is created by auto-generated standalone Java code (cf. the 
accidental manual duplicates in the four variants of Ecore/UML 
OCLStandardLibraryImpl.java, oclstdlib.*). This is controlled by an MWE 
script, as are editor generation, Pivot model generation and CST model 
generation. Acceleo and QVTo can reuse this transformation so that their 
standard 'Standard' libraries are also autogenerated.

I have the OCLinEcore editor maintaining Pivot Models that were loaded 
from Ecore. (saving to Ecore still to do, load/save from UML to do).

I have got some JUnit test cases successfully starting with a text 
query, creating a Pivot Model AST via the Xtext parser and then 
evaluating using the modelled standard library. This was the major gap 
in the Helios release and now makes everything model-driven with a 
single point of definition per concept.

I've generalised the grammar so that precedence and associativity are 
fully model-defined. This beneficially simplifies things for ANTLR 
avoiding the 65536 byte class limit when all non-reserved identifiers 
are enabled as identifiers.

I'm just starting on the Complete aspects of the Pivot Model whereby 
CompleteOCL contributions are installed in a uniform Pivot Model 
representation.

---

However the above is not comprehensive and needs extensive review, so
I'm not that confident of meeting a late October deadline for a 3.1.0 
release.

Since EMF and UML2 are so quiet (they do not even have project plans), I 
think we may be able to get very close to Indigo before we have a 
breaking dependency that prevents OCL 3.1 Mx running on Helios. I 
therefore propose to defer a preliminary 3.1 release until we need to 
increase lower version bounds to prohibit a Helios usage.

This will make each Mx release a bit more useful without the spurious 
impression of stability that '3.1.0' might imply.

	Regards

		Ed Willink