search

eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

6.0.0M5 editors fail to start on Juno SR2 #1457

Closed eclipse-ocl-bot closed 1 month ago

eclipse-ocl-bot commented 1 month ago

| --- | --- | | Bugzilla Link | 460661 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Feb 24, 2015 04:08 EDT | | Modified | Feb 26, 2015 12:13 EDT | | Blocks | 415232 | | Reporter | Ed Willink |

Description

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.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Feb 24, 2015 05:58

(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.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Feb 24, 2015 06:14

(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:

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.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Feb 26, 2015 12:13

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.