OCL/Dev/Releng/EndOfYear

The most important build activities are automated, but some require manual intervention and should be executed just before a release to ensure that procedures still work.

Models, Grammars and other auto-generated code

Classic OCL

The Classic OCL GenModels should be reloaded and regenerated and the changes checked to ensure that the code is compatible with the latest MF even though 2.7 compatibility is selected.

(In order to avoid Java 11 deprecation diagnostics, usage of e.g. "new Integer" are replaced by "Integer.valueOf".)

The LPG grammars are regenerated by the "LPG Parser" and "LPG Backtracking Parser" External Tools launches. Some manual restoration of Hava annotations is needed to make errors go away.

Pivot OCL

The "Generate OCL All" should regenerate all the pivot models. After cleaning up import and overrides, no significant changes should remain.

Documentation

The documentation is manually generated by the "OCL Documentation" External Tools launch. Once committed to GIT, the PDF may be promoted by selecting the pdfdoc option on the Jenkins job.

Javadoc

The Javadoc is generated and promoted by the Jenkins build when the Javadoc parameter is selected.

Release Currency

JET Compatibility

Action: Revise org.eclipse.ocl.examples.codegen/templates/model/*.javajet to track org.eclipse.emf.codegen.ecore/templates/model/*.javajet

If the evolved templates have new API, the per-release classes in org.eclipse.ocl.examples.codegen.genmodel.OCLGenModelUtil.java need to accommodate.

The weekly rns of the compatibility build jobs should detect whether OCLGenModelUtil fails to provide compatibility.

Build Compatibility

Action: Revise org.eclipse.ocl.examples.build MANIFEST.MF lower bounds.

OCL has binary compatibility with previous releases, however it only has build compatibility with the latest simultaneous release.

The most notable example of this build limitation occurs for EMF 2.14 for which the auto-generated GenModel templates use new API not present in EMF 2.13. Rebuilding using EMF 2.13 will not be compatible.

As discussed in 527458 the limitations on the build-time platform are imposed by tight lower bounds on EMF, UML2, MWE2, Xtext, QVTo in the org.eclipse.ocl.examples.build MANIFEST.MF.

Guava Compatibility

The code nominally works with any version of Guava, but is only compiled/tested against the latest provided by diverse sources.

Other versions of Guava may be tested by editing the ocl.eclipse.ocl.pivot MANIFEST.MF to explicitly import and re-export a specific com.google.guava version, which may be made available be dropping the relevant jar into the plugins directory.

Suggested versions to check for compilation/JUnit test errors are Guava 12, 15, 21. Using the 'wrong' version for JUnit plugin tests doesn't seem to work.

Eclipse Compatibility

The ocl-compatibility-oxygen job should be running every week on Jenkins to demonstrate that the Ecore, UML and Pivot tests run on an Oxygen platform.

This job may be interactively launched for Mars and Neon, for which Bug 527458 remains open for investigation of some strange test failures.

Standalone Compatibility

The ocl-ecore-standalone and ocl-uml-standalone jobs should be running every week on Jenkins to demonstrate that the Ecore and UML tests run on a Java 5 standalone classpath.

Pivot standalone testing awaits a resolution of Bug 535507.

Extra Tests

No-Internet tests

The standard JUnit tests should be run on a machine with no Internet connection to confirm that gratuitous nsURI loading off the Internet is not happening.

Consumer Tests

The org.eclipse.ocl.examples.consumers.tests plugin has additional tests for use within Papyrus. It would be good to get these working again.

CG

The ocl-codegen-tests job should be running every week on Jenkins to provide more intensive CG testing.

OOMPH

Check that the OOMPH setup works.