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

Bug 460661

Summary:	6.0.0M5 editors fail to start on Juno SR2
Product:	[Modeling] OCL	Reporter:	Ed Willink <ed>
Component:	Core	Assignee:	OCL Inbox <mdt-ocl-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3
Version:	unspecified
Target Milestone:	M6
Hardware:	PC
OS:	Windows NT
Whiteboard:
Bug Depends on:
Bug Blocks:	415232

Description Ed Willink

2015-02-24 04:08:05 EST

The 6.0.0M4 release installs and is plausibly useable with Juno SR2 modeling + the associated Xtext 2.3.1.

The 6.0.0M5 release is not. Starting up the OCLinEcore editor gives a Guice provisioning error that seems to be due to a bad *.xtextbin.

Between M4 and M5 there are major OCL changes including the refactoring of package names. Strong candidate, but ...

Xtext 2.8 has been evolving from compatible to incompatible, so there is also a fair possibility that an editir regeneration for the refactoring is giving an incompatible *.xtextbin.

Comment 1 Ed Willink

2015-02-24 05:58:43 EST

(In reply to Ed Willink from comment #0)
> seems to be due to a bad *.xtextbin.

The failure is an ArrayIndexOutOfBoundsException for a featureId early in the *.xtextbin reading.

Comparing M4 against a rebuild of commit 73a168b32210226f39583bef18823f0b6382fbba (11 days after M4 once the renames had settled down) both on Juno SR2:

The preamble reads ok verifying no \n\r corruption, but the first object count differs.

Using the same rebuild of commit 73a168b32210226f39583bef18823f0b6382fbba on Mars M5 and the *.xtextbin is ok. So the new *.xtextbin is not corrupt it is just not forward compatible.

The ArrayIndexOutOfBoundsException is caused by reading the new AbstractElement.firstSetPredicated feature that does not exist in Xtext 2.3.1.

firstSetPredicated was introduced in March 2014 (without an nsURI update) but caused no trouble then, even though it displaced Alternatives.elements from featureId 2 to 3. See Bug 460677.

Most likely trigger is an Essential OCL grammar change that affects some alternatives so that the new OCL grammar uses Alternatives.elements while the old grammar left it as default and so unserialized.

Comment 2 Ed Willink

2015-02-24 06:14:23 EST

(In reply to Ed Willink from comment #1)
> See Bug 460677.

Xtext will no doubt once again take the view that there is no forward compatibility. And there is also the problem that the incompatibility has been fully released. So cannot be undone.

Options:

- repair the *.xtextbin at run-time - not possible; the binary efficiency obfuscates the problem

- multiple *.xtextbin - one per Xtext.ecore variant; painful

- no *.xtextbin - revert to *.xmi; disappointing

Better - re-use the Pivot/OCLstdlib to Java serialization approach for the Xtext grammars so that the Grammar is constructed directly in memory eliminating some model loading.

Comment 3 Ed Willink

2015-02-26 12:13:59 EST

Main solution: Introduce a*.xtextbin to *GrammarResource.java M2T with a trivial GrammProvider that uses the static instance.

Pushed to master for M6:

commit a55dbe4b92a1f1b335bfb72261939c1aba5fa7cf

Also:

references to Resource.OPTION_LINE_DELIMITER replaced by a DerivedConstants definition

references ResourceDescriptionsProvider.PERSISTED_DESCRIPTIONS changed to the resolved value by BackportToXtext_2_3_1.

references to Xtext's BinaryGrammarResourceFactoryImpl replaced by OCL's BinaryGrammarResourceFactoryImpl to avoid a missing class and the catch complexity.