[
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?
|
Hi John, Sven
Thanks. It appears the double package provider is not a major concern,
so I've done my job by raising the possible issue.
OCL was easily fixed by changing the require bundle from
com.google.collect to com.google.guava.
Regards
Ed Willink
On 16/12/2011 06:28, Sven Efftinge wrote:
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
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1890 / Virus Database: 2108/4684 - Release Date: 12/16/11