Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] Xtext 2.8 forward incompatibility

Hi

The major compatibility issue has gone away. Xtext has reverted its breaking package name changes. (Editors generated with Xtext 2.8 M4 or M5 tooling should be regenerated using the latest Xtext N-build.)

Another issue remains (Bug 460677); 'safe' evolution of Xcore.ecore is unsafe when loading the *.xtextbin grammar since the loader of one Xtext.ecore version may have different featureIds to the saver using another Xcore.ecore version. I'm just finishing off the generator integration of a *.xtextbin replacement that uses static direct Java grammar 'loading' of the grammar and so avoids featureId index sensitivities, model loading and proxy resolution. Hopefully this might become part of the standard Xtext grammar access fragment.

For Eclipse OCL, I try to make no choice of Xtext version (other than Juno SR2, i.e. >= 2.3.1), since Eclipse OCL is rarely the most important Xtext consumer. Hence my concern to ensure compatibility with whatever some other consumer requires.

        Regards

                Ed Willink



On 23/02/2015 17:13, LETAVERNIER Camille wrote:
Hi Ed,

Thanks for the notice. I guess that's something we'll have to deal with shortly before M6.

In general, Papyrus has no specific compatibility to former Eclipse versions (We have many dependencies in the release train, including EMF/UML/QVTo/OCL/GMF/...), so it doesn't really make sense for us to ensure compatibility to anything else than the current version of the release train components. So I suppose we'll have to adhere with the choice made in OCL, and if possible, we'll migrate to the latest version of XText. The main thing we need to ensure is that all our XText plug-ins are consistent (I'm not sure whether XText is a singleton or not, but we definitely don't want two different versions of XText used by Papyrus)

Thanks,
Camille

-----Message d'origine-----
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Ed Willink
Envoyé : lundi 23 février 2015 17:27
À : mdt-papyrus.dev@xxxxxxxxxxx
Objet : [mdt-papyrus.dev] Xtext 2.8 forward incompatibility

Hi

Are you aware that Xtext 2.8 introduces a breaking forward incompatibility by renaming its "...ui..." plugins that are referenced by auto-generated code to "...ide..." plugins that are not available in Xtext 2.7 and earlier?


This is causing me considerable concern for OCL since for Luna I ensured that the Luna release was viable for Juno and Kepler.

In https://bugs.eclipse.org/bugs/show_bug.cgi?id=460552, I have found that a QVT editor developed using Xtext 2.8 cannot be installed as an extension of the OCL editor developed using Xtext 2.6/2.7. I have fixed the incompatibility by some simple automated package/class name edits.
This works for now but I'm not sure how long it will be before something less easy to correct appears.

An alternative, if Papyrus wants to avoid being tightly coupled to Xtext, may be to freeze at Xtext 2.7.3 for editor development and hope that future Xtext run-times have backward compatibility.

      Regards

          Ed Willink


_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5736 / Virus Database: 4293/9165 - Release Date: 02/23/15






Back to the top