Community
Participate
Working Groups
Some Xtext clients are platform+1 while Xtext is +2. Thus we have to be binary compatible. A first test revealed some incompatibilities (e.g. with the OCLInEcore implementation): java.lang.NoSuchMethodError: org.eclipse.xtext.formatting.impl.FormattingConfig.setNoSpace()Lorg/eclipse/xtext/formatting/impl/FormattingConfig$NoSpaceLocator; at org.eclipse.ocl.examples.xtext.oclinecore.formatting.OCLinEcoreFormatter.setParentheses(OCLinEcoreFormatter.java:199) at org.eclipse.ocl.examples.xtext.oclinecore.formatting.OCLinEcoreFormatter.configureFormatting(OCLinEcoreFormatter.java:55) at org.eclipse.xtext.formatting.impl.AbstractDeclarativeFormatter.getConfig(AbstractDeclarativeFormatter.java:70) at org.eclipse.xtext.formatting.impl.AbstractDeclarativeFormatter.createFormatterStream(AbstractDeclarativeFormatter.java:52) at org.eclipse.xtext.parsetree.reconstr.Serializer.serialize(Serializer.java:54) at org.eclipse.xtext.parsetree.reconstr.Serializer.serialize(Serializer.java:61) at org.eclipse.xtext.resource.XtextResource.doSave(XtextResource.java:283) [snip]
I've fixed the mentioned issue. The OCL-In-ECore editor N201005162112 can now be opened without an exception with our CVS HEAD.
This fixes all known issues with incompatibilities.
Closing bug which were set to RESOLVED before Eclipse Neon.0.