[
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