Community
Participate
Working Groups
Xtext currently generates: // contributed by org.eclipse.xtext.generator.builder.BuilderIntegrationFragment public void configureIResourceDescriptionsPersisted(com.google.inject.Binder binder) { binder.bind(org.eclipse.xtext.resource.IResourceDescriptions.class) .annotatedWith(com.google.inject.name.Names.named( org.eclipse.xtext.resource.impl.ResourceDescriptionsProvider.PERSISTED_DESCRIPTIONS)) .to(org.eclipse.xtext.... which uses the relocated PERSISTED_DESCRIPTIONS. Unfortunately prior to Xtext 2.6, this is an unresolved reference. If the generator instead emits the value of the constant as in: ....annotatedWith(com.google.inject.name.Names.named("org.eclipse.xtext.builder.impl.PersistentDataAwareDirtyResource.PERSISTED_DESCRIPTIONS")).... the incompatibility can be avoided. It may be beneficial to emit all constants by value to ensure that the resolveable value at generate-time rather than the potentially unresolveable value at run-time is used.
String constants are inlined into the class file. I don't understand the benefit of your sketched solution at runtime.
Ah!. That explains why I have not observed a runtime problem; just a source problem when setting the target platform to Juno SR2 and Xtext 2.3.1. If they are inlined, then there is zero difference in generated class files; just no errors in source files on an old platform.
