| Re: [modeling-pmc] Guava/Guice update and version bump |
|
Hi The Eclipse Versioning rules are strong; annoying and arguably not even strong enough. The last UML major version change forced OCL to make a major version chnage even though it wasn't necessary from an OCL point of view. However OCL took the opportunity to remove UML from the re-exported API so that the next UML version change will not mandate an OCL version change. Whenever you choose to re-export another project's bundle, you decide to be tightly coupled to that project; any major change in the referenced project mandates a major version change in the re-exporter. For primary platform and EMF plugins it is obviously impractical to avoid a tight coupling so why bother. But for secondary facilities such as EMF codegen or EMF compare, hiding the dependency may be highly beneficial. Thus Guice and Guava should never be re-exported. But Xtext is almost uniquely troublesome since the autogeneration
of code for the user imposes a requirement for both backward and
forward compatibility. With such a rich API, Xtext would be frozen
if it really imposed perfect API compatibility. EMF has a similar
problem that is largely solved by a run-time compatibility level
genmodel option. Injection perhaps makes Xtext's API too rich to
realistically do the same. Even the platform has now decided that a major version change to
4.x plugins is too horrible and so there are regular announcements
of removal of long-deprecated API. The removal totally violates
versioning policies. Xtext similarly needs to follow a pragmatic policy. In practice
Xtext 2.3 and Xtext 2.8 involved breaking changes that actually
mandated major version changes. org.eclipse.xtext currently re-exports com.google.inject but not org.objectweb.asm org.eclipse.xtext.util currently re-exports com.google.inject and com.google.guava Too late for Xtext 2.15. It could be announced that in Xtext 2.16 all usage of Guava/Guice/... in interfaces will be deprecated. Alternative API must be provided. This can be developed and tested by removing the re-exports and escalating all non-API-in-interface warnings to errors. However in the Xtext 2.16 release the re-exports must remain. It could also be announced that in Xtext 2.18 all re-exports of
Guava/Guice/... will terminate (without a major version change).
The old deprecated API could remain for much longer but would only
work for users who avoid inconsistent Guava choices. Currently OCL's editors do not impose a Guava version preferring to allow the re-exported Xtext version to be used avoiding an incompatibility. Once Xtext stops re-exporting, OCL's editor plugins will have the freedom to choose a different version to Xtext's plugins. In the past this was really bad, but if there is no leakage of Guava in interfaces, perhaps this problem is also solved. OCL's editor plugins can then, albeit accidentally, use a different Guava version to the underlying Xtext support plugins. I am not aware of any Guava in Xtext interfaces that OCL uses, so
once the missing imports are added, OCL editors should remain
compatible across a broad range of Xtext releases. Deferring the
removal till Xtext 2.18 without a major version change follows the
two-releases-notification that the platform now uses. Regards Ed Willink On 03/09/2018 07:22, Sven Efftinge
(sven@xxxxxxxxxxx) wrote:
|