OCL/New and Noteworthy/2024-03

Eclipse OCL New and Noteworthy items for the 2024-03 (6.20.0) release.

Release Overview

This minor release fixes a few minor bugs and one howler through introduction of a local validation registry.

Behind the scenes development of a new model-to-text formatter/serializer allows migration to the 'new' Xtext generator framework while retaining compatibility for Eclipse platforms from Oxygen onwards.

Eclipse versions

The prevailing Eclipse OCL release candidate is auto-tested every week on Oxygen, Photon, 2018-09, 2018-12, 2019-03, 2019-06, 2019-09, 2019-12, 2020-03, 2020-06, 2020-09, 2020-12, 2021-03, 2021-06 and 2021-09 platforms using Jenkins on Linux and the prevailing Java/project versions for the release.

2023-12 release should be installable on Mars and Neon platforms provided Xtext 2.9 or greater is also installed.

The 2023-12 sources may only be buildable on 2023-12.

Java versions

Java 11 on Windows was used to develop and test the milestones of this release. Following the Eclipse platform migration to a Java 17 minimum, development now uses Java 17, although standalone tests continue to use Java 8.

Java 17 on Jenkins, Linux was used to build and test the release candidates.

The Classic Ecore/UML plugins have been tested on Mars, Neon, Oxygen and Photon and on a Java 5 Virtual Machine. Standalone execution requires only the org.eclipse.osgi plugin from Eclipse Kepler or a spoof of org.eclipse.osgi.util.NLS and org.eclipse.osgi.framework.

The Pivot plugins require at least a Java 8 Virtual Machine and at least Xtext 2.9.1. Testing on Oxygen has a couple of test failures. Testing on Mars and Neon has a few editor/console startup failures.

Milestone 1

local validation registry

Since EMF provides only a global/static validation registry, previous OCL releases used it for local/dynamic requirements and attempted with limited success to mitigate leakage/concurrency problems.

The new OCL release introduces a local/dynamic validation registry as an adapter on a ResourceSet; the global validation registry is no longer abused. Problems solved, provided Java code is migrated to use the new ValidationRegistryAdapter.

Initialization must use the appropriate ResourceSet containing the model elements to be validated. Use

  ValidationRegistryAdapter.getAdapter(myResourceSet).put(myEPackage, myEValidator); 

rather than

  EValidator.Registry.INSTANCE.put(myEPackage, myEValidator);	

Validation should use the local validation registry. Use

  Diagnostician diagnostician = new Diagnostician(ValidationRegistryAdapter.getAdapter(myResourceSet));

rather than

  Diagnostician diagnostician = Diagnostician.INSTANCE;

The new ValidationContext can make the usage a bit more readable:

  ValidationRegistryAdapter validationRegistry = ValidationRegistryAdapter.getAdapter(myEObject);
  ValidationContext validationContext = new ValidationContext(validationRegistry);
  Diagnostician diagnostician = validationContext.getDiagnostician();
  Diagnostic diagnostics = diagnostician.validate(myEObject, validationContext);

Failure to use the local validation registry may lose validations.

Pivot

• 582494 Use local validation registry

Releng

Migrate to Java 17 when using the platform but continue to test Java 5 and Java 8 compatibility on legacy platforms.

Accommodate package migrations such as javax.annotation.

Accommodate restructuring/reduced Orbit content.

Milestone 2

Releng

Avoid redistributing a duplicate LPG now that Orbit provides a SimRel distribution.

Milestone 3

Behind the scenes the deprecated 'old' Xtext generator framework has been revised to use the 'new' framework. The inadequacies of the new serializer/formatter are avoided by the development of a declarative idiom-based serializer/formatter, allowing the longstanding formatting bug in multi-line comments to be fixed.

(The declarative idiom-based serializer/formatter was initially developed with the intention of contributing yet another 'new' aspect to the 'new' Xtext framework. However when it was applied to Xtext itself, a significant but trivial problem arose through the assumption that the mapping from Node model to EMF model was bijective (bidirectionally lossless). Unfortunately Xtext 'optimises' gratuitous parentheses preventing a serializer reconstructing the text source accurately. Since all OCL and QVTd editors were bijective, I ran out of enthusiasm for solving problems that did not affect OCL or QVTd. The clones and packaging necessary for a self-standing contribution were therefore folded back into org.eclipse.ocl.xtext.base.serializer for the run-time and org.eclipse.ocl.examples.build.analysis supporting org.eclipse.ocl.examples.build.fragments.{DeclarativeFormatterFragment, DeclarativeSerializerFragment) for the generator.)

• 563046 Use 'new' Xtext generator framework