Difference between revisions of "OCL/Dev/Releng/EndOfYear"
|Line 17:||Line 17:|
The documentation is manually generated by the "OCL Documentation" External Tools launch. Once committed to GIT, the PDF may be
The documentation is manually generated by the "OCL Documentation" External Tools launch. Once committed to GIT, the PDF may be by selecting the pdfdoc option on the Jenkins job.
Revision as of 11:31, 5 December 2018
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.
- 1 Models, Grammars and other auto-generated code
- 2 Release Currency
- 3 Extra Tests
Models, Grammars and other auto-generated code
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.
The "Generate OCL All" should regenerate all the pivot models. After cleaning up import and overrides, no significant changes should remain.
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.
The Javadoc is generated and promoted by the Jenkins build when the Javadoc parameter is selected.
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.
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.
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.
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.
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.
The org.eclipse.ocl.examples.consumers.tests plugin has additional tests for use within Papyrus. It would be good to get these working again.
The org.eclipse.ocl.examples.xtext.tests (CG) launch should be run to provide more intensive CG testing.
Check that the OOMPH setup works.