You've encountered a split-packages problem. That is, while multiple bundles can export a package, a bundle can only import from one of them.
In general, split-packages are a bad thing and break modularization. But, they are a reality and so there are a few ways to deal with them. I hesitate to suggest it, but Require-Bundle is one way...instead of importing the package, require the whole bundle. But use Require-Bundle very carefully, as it creates an undesirable bundle-to-bundle coupling. Another way I've dealt with it is to embed one bundle in the other (actually, the embedded one doesn't even have to be a bundle...a plain JAR will work). Be sure to put the embedded JAR in the outer bundle's Bundle-ClassPath. Then, when the outer bundle exports the package, the entire package will be exported (from both JARs). This is especially useful if the embedded JAR file is only useful within the context of the bundle it is embedded in. For example, I did with with Lucene and Compass. Both export some of the same Lucene packages. So, I embedded Lucene within a Compass bundle because I wasn't planning on using Lucene without Compass. Others on this list may have other suggestions, but these are the two I've used. > Hi, > So I have this case when I have two (or more) bundles exporting the same > package, but different classes in them and I have another bundle which is > importing classes from this package. The problem is that I am getting an > error saying that some classes could not be found, i.e. classes from this > common package. It seems as though the importing is possible only from one > of the bundles. Importing the same package in those bundles in a manifest > does not help. > > I am using google guice and basically the error is originated in guice > when > it tries to inject one of those imported classes. I am suspecting that it > has something to do with it, probably proxies guice creates or something > like that. > > Does anybody know what I am talking about here? Any solutions? Bridge > classloaders maybe? > > Thanks! > > -- > Dmitry Skavish > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
