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 [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
