eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

[project] Accommodate Xtext 2.9 serializer #1636

Closed eclipse-ocl-bot closed 1 month ago

eclipse-ocl-bot commented 1 month ago

| --- | --- | | Bugzilla Link | 481867 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Nov 10, 2015 14:05 EDT | | Modified | Oct 26, 2016 04:41 EDT | | Depends on | 481865, 488643 | | Reporter | Ed Willink |

Description

Xtext 2.9 generates incompatible serializers. See Bug 481865.

It may be that regenerating all editors with the new

generateSupportForDeprecatedContextObject = true

but it doesn't seem to actually be available.

For now all generation must use Xtext 2.8.4 maximum.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Nov 10, 2015 14:57

2.9 also requires

additional.bundles = org.eclipse.xtext.common.types

in build.properties.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Feb 24, 2016 05:24

(In reply to Ed Willink from comment #0)

It may be that regenerating all editors with the new

generateSupportForDeprecatedContextObject = true

generateSupportForDeprecatedContextEObject is there in Xtext 2.10.0M5.

Regenerating just the OCL Base Editor with this works; all OCL and QVTd tests pass.

Regenerating all OCL editors with this works; all OCL and QVTd tests pass.

But the regenerated editors need Xtext 2.9 to satisfy the ISerializationContext dependency.


In the absence of a compatibility fix for Bug 481865, choices are:

OCL 6.1 for Neon is a minor release so not being installable as a 6.0 upgrade is unsatisfactory, so for Neon, I think we should stick to Xtext 2.8.4 tooling and Xtext 2.3.1 compatibility..

Lagging behind current Xtext releases will get increasingly painful, so for Oxygen and OCL 7.0 we may need to move to Xtext 2.10.0 minimum.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Feb 25, 2016 05:03

(In reply to Ed Willink from comment #2)

OCL 6.1 for Neon is a minor release so not being installable as a 6.0 upgrade is unsatisfactory, so for Neon, I think we should stick to Xtext 2.8.4 tooling and Xtext 2.3.1 compatibility..

This unfortunately means that on Neon, anyone who wants to generate an OCL-based editor must use Mars tooling.

There is a third choice that has already been adopted for some trivial backward incompatibilities: auto-edit the generated references to the 'missing' class. A full code correction looks troublesome, but maybe just the import can be changed to something that we provide.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Feb 28, 2016 02:12

(In reply to Ed Willink from comment #3)

There is a third choice that has already been adopted for some trivial backward incompatibilities: auto-edit the generated references to the 'missing' class. A full code correction looks troublesome, but maybe just the import can be changed to something that we provide.

Messing around with compatibility pseudo classes is hard, but there is a relatively straightforward set of edit rules that can migrate AbstractXXXSemanticSequencer to compatible form. Another edit rule on InternalXXXParser can redirect the new unpackEncodedStringArray method to a compatibility implementation. However the resulting migration gives a Guice crash as it starts. The problem is that Xtext 2.10 rules are fully qualified

    private final ParserRule rule = (ParserRule) GrammarUtil.findRuleForName(getGrammar(), "org.eclipse.ocl.xtext.base.Base.MultiplicityBoundsCS");

compared to before

    private final ParserRule rule = (ParserRule) GrammarUtil.findRuleForName(getGrammar(), "MultiplicityBoundsCS");

consequently every rule lookup fails.

The qualification is an incompatible step forward no doubt to support multi-grammars.

We could have more edit rules to correct all the grammar literals, but what are we achieving apart from increasingly fragile weird code?


a) rebuilding and distributing with Xtext 2.10, a Neon OCL distribution cannot be installed on Xtext < 2.9 i.e. not on Mars.

b) rebuilding and distributing with Xtext 2.8.4, a Neon OCL distribution can be probably be installed on Juno...Neon. OCL-extending editors must build with Xtext < 2.9.

c) rebuilding with Xtext 2.10 and adjusted tooling, a Neon OCL distribution can be probably be installed on Juno to Neon. OCL-extending editors must build with our adjusted tooling.


c) adjusted tooling seems to cause pain for us and for OCL-extending editors. The adjusted tooling is not part of the distribution, so must be installed from GIT.

b) requires a variant installation (? or target platform) when developing OCL-extending editors.

a) inhibits the Neon OCL 6.1 being installed as a Mars OCL 6.0 upgrade.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Feb 28, 2016 05:51

(In reply to Ed Willink from comment #2)

so for Neon, I think we should stick to Xtext 2.8.4 tooling and Xtext 2.3.1 compatibility..

Same conclusion after further investigation. Bug 488643 raised wrt Xtext runtime incompatibility.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Jun 06, 2016 07:37

(In reply to Ed Willink from comment #5)

(In reply to Ed Willink from comment #2)

so for Neon, I think we should stick to Xtext 2.8.4 tooling and Xtext 2.3.1 compatibility..

The first user having trouble with this has appeared on the Xtext newsgroup "IllegalValueException when extending EssentialOCL".

If OCL for Oxygen is 6.2 rather than 7.0, this problem is going to get more pervasive. Having to use Xtext 2.8.4 for editor regenerates is already a PITA.

There seem to be only two approaches without losing pre-Neon compatibility.

a) Multiple builds (e.g. "6.1 for Neon" and "6.1 for Luna/Mars"). A major PITA to set up and to maintain thereafter, although once done it may solve other related problems.

b) Repair the generator fragment. Ideally Xtext will recognize that this is their responsibility and do it right and maintain it. If OCL does it, it will probably be a fudge and will be fragile thereafter.

Only b) is really a solution.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Jun 08, 2016 08:47

(In reply to Ed Willink from comment #6)

b) Repair the generator fragment. Ideally Xtext will recognize that this is their responsibility and do it right and maintain it. If OCL does it, it will probably be a fudge and will be fragile thereafter.

Only b) is really a solution.

A modified SerializerFragment is not that hard, and could easily be migrated back to Xtext. See branch archive/481867.

But read the earlier comments before wasting yet more fruitless time.

(In reply to Ed Willink from comment #4)

However the resulting migration gives a Guice crash as it starts. The problem is that Xtext 2.10 rules are fully qualified

This really cannot be worked around. Xtext 2.9 is fundamentally incompatible with Xtext 2.8.4.

(In reply to Ed Willink from comment #6)

a) Multiple builds (e.g. "6.1 for Neon" and "6.1 for Luna/Mars"). A major PITA to set up and to maintain thereafter, although once done it may solve other related problems.

is the only solution. But it's too hard.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Oct 26, 2016 04:41

(In reply to Ed Willink from comment #7)

A modified SerializerFragment is not that hard, and could easily be migrated back to Xtext. See branch archive/481867.

It was actually "archive/415146" (8 Jun 2016).

But given the qualified name difficulties, the archive is not worth keeping. Deleted.

(In reply to Ed Willink from comment #6)

a) Multiple builds (e.g. "6.1 for Neon" and "6.1 for Luna/Mars"). A major PITA to set up and to maintain thereafter, although once done it may solve other related problems.

is the only solution. But it's too hard.

Eventually opted for a double build.

6.1 for Neon using Xtext 2.8 to generate. 6.2 for Neon++ using Xtext 2.10 to generate.\ (6.3 for Oxygen).

Both 6.1 and 6.2 are maintained identically. So we have a one year transition before extension language developers must regenerate as well.