Bugzilla – Full Text Bug Listing
| Summary: | [xtext][deps] Guava 11 compatibility | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] TMF | Reporter: | Knut Wannheden <knut.wannheden> | ||||||
| Component: | Xtext | Assignee: | Project Inbox <tmf.xtext-inbox> | ||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | benjamin.schwertfeger, cps, dennis.huebner, ed, idydieng, mknauer, sebastian.zarnekow, stephaneberle9, sven.efftinge, thay.huynhdacca, wolfgang.haug | ||||||
| Version: | 2.3.0 | Flags: | sven.efftinge:
kepler+
|
||||||
| Target Milestone: | M7 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 404313 | ||||||||
| Attachments: |
|
||||||||
|
Description
Knut Wannheden
I agree. We should investigate how much work it is to replace the code we uses which is no longer available in Guava 11. Knut, could you have a look? Yes, I will take a look at this. It's unfortunate that binary compatibility was already broken for the new CacheBuilder. I will look into alternatives (the old style MapMaker would be a possibility but it's marked as deprecated in Guava 11). We also face this problem with class DefaultResourceDescriptionDelta at line 92. I suggest we can change to ImmutableSet.copyOf(E[] elements) in this class Thanks, Created attachment 210924 [details]
changed class DefaultResourceDescriptionDelta
changed class DefaultResourceDescriptionDelta
I attached the changed class DefaultResourceDescriptionDelta to this bug (In reply to comment #5) > I attached the changed class DefaultResourceDescriptionDelta to this bug A corresponding fix has already been committed. This is the only source incompatibility with Guava 11 in the Xtext code base. But note that there are binary incompatibilities as originally reported. This still need to be fixed. Created attachment 211842 [details]
patch for Activator.xpt
Unfortunately neither MapMaker nor CacheBuilder is a good choice at the moment due to backward and forward compatibility issues. So for the incompatibility problem in the activator class I had a very simple patch in mind (see attachment). Any thoughts?
Looks good at a first glance. No scenario comes to my mind where we could run into deadlocks with the synchronized access to the injector-map. Generated OSGi activator classes now no longer depend on Guava's CacheBuilder (see http://git.eclipse.org/c/tmf/org.eclipse.xtext.git/commit/?id=eb7413479cc100bb791dc4cb5e698e665b6b75ac). It remains to be seen if there are other Guava 11 binary incompatibilities which need fixing. Before I forget: Could someone take care of regenerating and committing MWE2? (In reply to comment #10) > Before I forget: Could someone take care of regenerating and committing MWE2? Thanks for the reminder. Regenerated and pushed to master. I think we can close this one. If other incompatibilities arise, we should track them in individual tickets. Thanks for the effort, Knut! I'm glad this is fixed but the underlying problem was caused by Xtext depending on @Beta API's in guava. It would be best to avoid any @Beta API's in the future. Hi Chris, You are absolutely right about that. I reopens the bug because it seems when Xtext is used with other plug-ins that depend on Guava version 10 we still have this problem. For example, we got the same problem using the Eclipse Automotive IWG Kepler M6 IDE (available here http://build.eclipse.org/technology/epp/epp_build/kepler/download/20130320-2356/). Can you please have a look Yes, you are right. Another dependency on the Guava 10 @Beta annotated CacheBuilder was introduced with commit http://git.eclipse.org/c/tmf/org.eclipse.xtext.git/commit/?id=cdf61925452dbb8b19ba9eceaa01009f743178ff. This needs to be changed for Xtext to be compatible with never Guava versions. see bug 404313 I have tried Kepler M6 with installing Xtext, Xtend and others into Downloaded classic version. The xtext-builder fails with: java.lang.NoSuchMethodError: com.google.common.cache.CacheBuilder.build(Lcom/google/common/cache/CacheLoader;)Lcom/google/common/cache/Cache; The guava plugins in my eclipse are 10.0.1 and 11.0.2. I can not tell, which one is used by the builder. I just deleted 11 from the installation plugins and the problems go away. Since this problem stems from @Beta annotation usage, and since Eclipse aspires to good runtime compatibility, should the Orbit distributions of Guava suppress all external access to @Beta code? I think FindBugs or PMD can mark usages of @Beta code. Pushed to review. Reopening because we still get the exception pasted below after importing the domain model example into the workspace. We are using the Kepler M7 build of the Eclipse Automotive IDE which is available here: http://build.eclipse.org/technology/epp/epp_build/kepler/download/20130509-1108. and has com.google.guava_10.0.1.v201203051515.jar and com.google.guava_11.0.2.v201303041551.jar in its plugins folder. java.lang.NoSuchMethodError: com.google.common.cache.CacheBuilder.build(Lcom/google/common/cache/CacheLoader;)Lcom/google/common/cache/Cache; at org.eclipse.xtext.ui.preferences.EclipsePreferencesProvider.getPreferenceValues(EclipsePreferencesProvider.java:44) at org.eclipse.xtext.xbase.ui.validation.XbaseIssueSeveritiesProvider.getIssueSeverities(XbaseIssueSeveritiesProvider.java:34) at org.eclipse.xtext.xbase.typesystem.internal.DefaultReentrantTypeResolver.getIssueSeverities(DefaultReentrantTypeResolver.java:136) at org.eclipse.xtext.xbase.typesystem.internal.RootResolvedTypes.<init>(RootResolvedTypes.java:67) at org.eclipse.xtext.xbase.typesystem.internal.DefaultReentrantTypeResolver.createResolvedTypes(DefaultReentrantTypeResolver.java:203) at org.eclipse.xtext.xbase.typesystem.internal.DefaultReentrantTypeResolver.resolve(DefaultReentrantTypeResolver.java:158) at org.eclipse.xtext.xbase.typesystem.internal.DefaultReentrantTypeResolver.reentrantResolve(DefaultReentrantTypeResolver.java:147) at org.eclipse.xtext.xbase.typesystem.internal.DefaultBatchTypeResolver$1.reentrantResolve(DefaultBatchTypeResolver.java:122) at org.eclipse.xtext.xbase.typesystem.internal.CompoundReentrantTypeResolver.reentrantResolve(CompoundReentrantTypeResolver.java:63) at org.eclipse.xtext.xbase.typesystem.internal.CachingBatchTypeResolver$LazyResolvedTypes.delegate(CachingBatchTypeResolver.java:114) at org.eclipse.xtext.xbase.typesystem.internal.CachingBatchTypeResolver$2.process(CachingBatchTypeResolver.java:61) at org.eclipse.xtext.xbase.typesystem.internal.CachingBatchTypeResolver$2.process(CachingBatchTypeResolver.java:1) at org.eclipse.xtext.util.concurrent.IUnitOfWork$Void.exec(IUnitOfWork.java:36) at org.eclipse.xtext.util.OnChangeEvictingCache.execWithoutCacheClear(OnChangeEvictingCache.java:127) at org.eclipse.xtext.xbase.typesystem.internal.CachingBatchTypeResolver.resolveTypes(CachingBatchTypeResolver.java:58) at org.eclipse.xtext.xbase.resource.BatchLinkingService.resolveBatched(BatchLinkingService.java:45) at org.eclipse.xtext.xbase.resource.BatchLinkableResource.resolveLazyCrossReferences(BatchLinkableResource.java:141) at org.eclipse.xtext.EcoreUtil2.resolveLazyCrossReferences(EcoreUtil2.java:510) at org.eclipse.xtext.builder.clustering.ClusteringBuilderState.doUpdate(ClusteringBuilderState.java:210) at org.eclipse.xtext.builder.builderState.AbstractBuilderState.update(AbstractBuilderState.java:104) at org.eclipse.xtext.builder.impl.XtextBuilder.doBuild(XtextBuilder.java:168) at org.eclipse.xtext.builder.impl.XtextBuilder.fullBuild(XtextBuilder.java:194) at org.eclipse.xtext.builder.impl.XtextBuilder.build(XtextBuilder.java:89) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:726) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:321) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:396) at org.eclipse.core.internal.resources.Project$1.run(Project.java:618) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2345) at org.eclipse.core.internal.resources.Project.internalBuild(Project.java:597) at org.eclipse.core.internal.resources.Project.build(Project.java:124) at org.eclipse.xtext.builder.impl.BuildScheduler$BuildJob.run(BuildScheduler.java:178) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) I think Bug 407686 is another Guava issue that breaks Papyrus. (In reply to comment #22) > and has com.google.guava_10.0.1.v201203051515.jar and > com.google.guava_11.0.2.v201303041551.jar in its plugins folder. Feature org.eclipse.emf.compare includes com.google.guava 11.0.2.v201303041551. Features org.eclipse.xtext.runtime includes version 10.0.1.v201203051515 Looking deeper into the bundles: org.eclipse.xtext.util, org.eclipse.xtext.xbase.lib, org.eclipse.xtext.builder, and org.eclipse.xtext.xbase.junit require version 10.0.1 of Guava, but none of them defines an upper version limit. (In reply to comment #22) > Reopening because we still get the exception pasted below after importing > the domain model example into the workspace. We are using the Kepler M7 > build of the Eclipse Automotive IDE which is available here: > > http://build.eclipse.org/technology/epp/epp_build/kepler/download/20130509- > 1108. Can't reproduce this issue. Are you sure you are using the latest Xtext 2.4.2M7? Cache builder functionality was implemented using MapMaker see: https://git.eclipse.org/c/tmf/org.eclipse.xtext.git/commit/?id=a3c49a948d4542df019c05cd8cf8700e41e99ae7 (In reply to comment #25) > (In reply to comment #22) > > http://build.eclipse.org/technology/epp/epp_build/kepler/download/20130509- > > 1108. > Can't reproduce this issue. > Are you sure you are using the latest Xtext 2.4.2M7? I'm using the Xtext build that went into above mentioned build of the Automotive packages. Normally, it should be Xtext 2.4.2M7, i.e., the M7 build of Xtext's Kepler development stream. When you were trying to reproduce the issue, have you been using the Automotive IDE package from above mentioned link? If so, note that I was testing under Windows 64-bit and that we already had the same problem with the Kepler M6 build of the Automotive IDE package. IMO, the hint from Markus goes into the right direction. This issue is most certainly only present when Xtext is used with some other component expecting a different version of Guava. Introducing explicit version constraints in the plug-ins depending on Guava could potentially avoid such kind of interoperability issues. Bug 407711 and 407686 are probably yet more manifestations of this nightmare that has arisen in M7 where Guava 10, 11 and 12 are all installed at once. (In reply to comment #26) > (In reply to comment #25) > > (In reply to comment #22) > > > http://build.eclipse.org/technology/epp/epp_build/kepler/download/20130509- > > > 1108. > > Can't reproduce this issue. > > Are you sure you are using the latest Xtext 2.4.2M7? > > I'm using the Xtext build that went into above mentioned build of the > Automotive packages. Normally, it should be Xtext 2.4.2M7, i.e., the M7 > build of Xtext's Kepler development stream. > > When you were trying to reproduce the issue, have you been using the > Automotive IDE package from above mentioned link? I've used a link from Markus email to epp-dev: http://build.eclipse.org/technology/epp/epp_build/kepler/download/20130509-1108/ The automotive package contains the latest stable Xtext 2.4.2M7 > If so, note that I was > testing under Windows 64-bit and that we already had the same problem with > the Kepler M6 build of the Automotive IDE package. > > IMO, the hint from Markus goes into the right direction. This issue is most > certainly only present when Xtext is used with some other component > expecting a different version of Guava. Introducing explicit version > constraints in the plug-ins depending on Guava could potentially avoid such > kind of interoperability issues. We would like to allow users to use a newer guava version if they want, therefor we have no upper bound set. Xtext is guava 14 compatible right now, and we have tests running against the most recent guava version to catch this kind of bugs as soon as possible. (In reply to comment #28) > (In reply to comment #26) > > (In reply to comment #25) > > > (In reply to comment #22) After a discussion of this problem between Dennis and me on the phone, we were able to figure out the root cause: In the Windows versions of the Automotive IDE package, both Xtext 2.4.0 and Xtext 2.4.2 plug-ins are present whereas in the MacOsX versions of the same package only Xtext 2.4.2 plug-ins are present. And in Xtext 2.4.0 this bug was not yet fixed. So, we can definitely close the discussion here and handle the resolution of this issue on EPP side. (In reply to comment #29) > In the Windows versions of the Automotive IDE package, both Xtext 2.4.0 and > Xtext 2.4.2 plug-ins are present whereas in the MacOsX versions of the same > package only Xtext 2.4.2 plug-ins are present. And in Xtext 2.4.0 this bug > was not yet fixed. I checked both Windows (x86 + x86_64) and all other Automotive IDE packages and couldn't spot any org.eclipse.xtext bundles != 2.4.2. It must be something else. Maybe a directory that still contained some old content? (In reply to comment #30) > (In reply to comment #29) > > In the Windows versions of the Automotive IDE package, both Xtext 2.4.0 and > > Xtext 2.4.2 plug-ins are present whereas in the MacOsX versions of the same > > package only Xtext 2.4.2 plug-ins are present. And in Xtext 2.4.0 this bug > > was not yet fixed. > > I checked both Windows (x86 + x86_64) and all other Automotive IDE packages > and couldn't spot any org.eclipse.xtext bundles != 2.4.2. It must be > something else. Maybe a directory that still contained some old content? I was just doing the same check. But: During our test of Xtext in the Automotive IDE package we first install the Xtext SDK from the Kepler Update site (http://download.eclipse.org/releases/kepler). This is necessary because the package contains as it should only the runtime plug-ins but no sources and no examples. We then import the Domain Model example project and see if everything is ok. I just checked which version of Xtext is in the Kepler update site right *now*. To my surprise it is Xtext 2.4.0. Does this mean that the Kepler update site just contained an old version, namely 2.4.0, by the time where I was testing (late yesterday evening)? Yesterday /releases/kepler did not yet contain the new Kepler M7 content, that changed only today. But even today I'd be very careful because (a) p2 caches and some http network proxies may still influence the content in some way, and (b) /release/kepler is a composite repository and contains content from the last 3 milestones (currently M5, M6, M7). /releases/staging would have been yesterday the most consistent p2 repository with exactly the content that had been used to build the packages. But I am glad that we finally found the source of our problem. Maybe you can re-test the package with the Kepler M7 repository enabled, and hopefully we can close the bug then. (In reply to comment #32) > Maybe you can > re-test the package with the Kepler M7 repository enabled, and hopefully we > can close the bug then. I just did, and everything went through very smoothly :) I'll refer to the /release/staging repo next time. (In reply to comment #33) > I just did, and everything went through very smoothly :) That's good news before the weekend! ;-) Requested via bug 522520. -M. Requested via bug 522520. -M. |