Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Is it acceptable to have two com.google.common.collect providers?

Ed, 

> No they are not interchangeable, which is how I came across the problem.
> 
> They both do magic ClassLoader wizardry to support injection, and so when some plugins use variant A and dependent plugins use variant B the end result is a Guice class injection failure.

you were talking about google collect and guava. It seems like you are confusing them with guice now?
I also don't understand what kind of class loader magic you are referring to.
Which bundles exactly cause the problem?

> 
> For OCL, the problem was avoidable. Xtext uses variant A and OCL's extended Xtext used variant B, so an M4a OCL build corrects it.
> 
> However it may not be avoidable tomorrow, because Acceleo also uses variant B, so if I have a plugin dependent on both Acceleo and Xtext, my plugin must use both variant A and B.

com.google.common.collect is exported in two different versions from two different bundles. Apart from a single method the newer version from guava is are 100% backwards compatible.
So Xtext and Acceleo should work find with guava on the class path.

> 
> From a different perspective, it seems a break in binary compatibility. Since both packages are available somewhere in the staging repository, P2's standard 'find the missing bits' enables an Xtext editor that hasn't been fully rebuilt to install correctly but fail at run time.

If you have a require-bundle import to the old google-collect you need to make sure that the bundle is there.
If you have an import package both should work fine (unless you use the method mentioned above)

Sven

Back to the top