[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [mdt-ocl.dev] Indigo SR0 editors don't run on SR2
|
Hi Ed,
unfortunately we don't have concrete plans for a 2.2.2. nor do we have the resources to test a complete language implementation that was developed against 2.0.1 with 2.2.1. A patch that fixes the problems would be helpful.
Regards, Sebastian
On 15.02.2012, at 09:10, Ed Willink wrote:
Hi Sebastian
Thanks. If Xtext 2.0.1 goes to SR2 there is no Eclipse problem. It's
just the convenience hybrid download from itemis that accidentally
locks out some third party code. Perhaps you can create a dummy
fully-featured Indigo SR0, Juno SR0 etc editor that you can use for
smoke testing your enhancements. While on the consumer side I see
annoying changes, from your point of view I can see that it is very
difficult to ensure compatibility; Guice totally bypasses all the
API tooling. Perhaps you want to write your own reflective analysis
of the RuntimeModule API so that you can check that all new
functionality has defaults. Any chance that you can do an Xtext
2.2.2 that provides the missing API defaults?
It's getting a bit late to change things for SR2, so I'd prefer to
leave it, particularly if you can restore compatibility. We would
need an upper bound that prohibited Xtext 2.2.1 but allowed 2.2.2.
Regards
Ed
On 15/02/2012 07:23, Sebastian Zarnekow wrote:
Hi Ed,
please be aware of the fact that we contribute Xtext 2.0.1 to Indigo SR2. The distro from download location that you mentioned in the bug bundles a newer version of Xtext.
However, we'll try to avoid these problems for future releases. Meanwhile you may want to set an upper bound for Xtext in your SR2 contribution?
Best regards,
Sebastian
On 15.02.2012, at 08:17, Ed Willink wrote:
Hi
Xtext 2.2.1 for (SR2) appears to have changed 'internal' APIs and so attempting to run OCLinEcore 3.1.1 with Xtext 2.2.1 gives editor instantiation failures.https://bugs.eclipse.org/bugs/show_bug.cgi?id=371574.
While this is clearly an Xtext problem, it isn't going to be fixed for SR2 or SR2a, we can just hope that itemis learn how many of their 'internal' APIs are actually external and avoid the problem in the future.
Anyway it is our user's problem, so I think we need to create a 3.1.2X release in which we regenerate editors and raise the lower bound on Xtext to 2.2.1 to force compatibility. This is of course not allowed in an SR, so it isn't an SR as such. Is an X suffix enough, or do we want a longer more distinct name? Adolfo: is there any spelling that is particularly easy for releng?
Regards
Ed
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1913 / Virus Database: 2112/4809 - Release Date: 02/14/12
_______________________________________________ mdt-ocl.dev mailing list mdt-ocl.dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
|
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail