Community
Participate
Working Groups
(moved over from https://issuetracker.springsource.com/browse/STS-1806) It seems that STS does not properly support the Bundle-Classpath in the BundleClasspathContainer. create bundle project com.acme.example copy jar file containing some source, e.g. package com.acme.example with interface ExampleService add jar to Bundle-Classpath Now, on the runtime tab of the manifest editor I cannot add the package export com.acme.example. When I manually add the jar to the build path I can select the package in the export package section (note: when adding the Export-Package statement manually, I get a warning saying 'Bundle does export non-existing package'). When I add the com.acme.example bundle (with embedded jar on Bundle-Classpath) to the Virgo repository and try to import com.acme.example, the package is found in the 'Add...' dialog on the dependencies tab of the manifest editor. However, the bundle classpath container seems to be incorrect (under the 'Bundle Dependencies' classpath container the jars appear containing the embedded jars but not showing their content). Any reference to the package com.acme.example creates a compiler error. However, if I deploy the dependent bundle it resolves correctly in Virgo. So, the Bundle-Classpath and the Jar are definitely ok. However, STS seems to have problems with that setup. I think it should be pretty easy to reproduce given the above recipe. Let me know if I can be of further assistance. To fix this issue I expect: a) that the manifest editor properly recognizes packages in embedded jar files b) that the bundle classpath container properly reflects types in embedded jar files PS: I've tried to use the bundle org.apache.httpcomponents.httpcore in one of my projects
OK, I'm not sure that we *should* support this. Embedded jars are haveily discouraged for Eclipse bundles in general. Jars should be deployed as plugin-jars. This seems to me to be consistent with an overall OSGi friendly approach. Is this really a use case we need to support for users, or should we instead focus encourage the deploying of jars correctly through project warnings? Thoughts?
My use case was using a library that was so OSGi-hostile that it was simply the easiest way to embed all required Jars in the bundle. OSGi-fying the library would have been close to impossible. Through embedding the library saw all it's required resources and classes on the classpath and worked flawlessly. While I agree that embedded Jars should be avoided, I still think it would be reasonable to support them. After all, all OSGi containers support it too.
Fair enough. Did you try "Plugin-in from Existing Jar archives"? Were you able to find another decent work-around? Not trying to push back on it, just trying to work through some triage priorities.
I realized that I could live without that particular library, that's how I got around the issue. I could have unpacked all the jars of the library (there were many), as you've mentioned. So I was just a bit lazy. Still, at least a decent warning / error would be great.
OK, thanks for the feedback Alfredo. FWIW, that's how I usually feel about this issue -- it's a PITA to deal with, but it's usually worth the pain. However, we really do need to support it, at the very least so that we don't break people's existing stuff. If people have an immediate need for this fix, please do comment or vote and we'll move it up the queue. N.B. for people who don't have background on this: In addition to compatibility issues, embedded jars can cause performance and space issues in Equinox context and won't work in some other contexts. See for example: http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg02251.html
