Community
Participate
Working Groups
Using the latest pde.runtime from HEAD: org.eclipse.core.runtime, core.runtime.compatibility, org.eclipse.swt and the org.eclipse.osgi.* plugins do declare libraries, but these libraries are not shown in the registry view. One thing common among these plug-ins is that they are the only ones that have a manifest.mf (i.e. they are true bundles), so the registry processing algorithm might need a little tweaking to pick up these somewhat structurally different plug-ins.
I am not sure about the compatibility with the registry, but I think that only extensions and extension points are still showing for bundles. The rest needs to be fetched from the bundle itself.
way to remove the mystery out of the defect, Dejan ;-) That was for Cherie to figure out.
+1 for Dejan :)
Ah :-(. I didn't realize it was a trick question :-(.
Will be using Bundle.getHeader() to get runtime libraries. The problem is that it will not always return the complete list of runtime libraries. Thus, we can only see the declared libraries for core.runtime, core.runtime.compatibility, osgi.services, and osgi.util right now. This is a temporary solution (see below) until the ILibrary implementation is complete. Going to resolve to REMIND in the meantime. Reference from the porting guide: ILibrary implementation incomplete Who is affected: User of org.eclipse.core.runtime.ILibrary. Description: The new runtime maintains the classpath entries in a different and incompatible form from Eclipse. As a result, the compatibility layer is unable to correctly model the underlying OSGi structures as ILibrary objects. Action required: Users of ILibrary should consider accessing the desired header values (e.g., Bundle-Classpath) from the appropriate Bundle (see Bundle.getHeaders()) and using the ManifestElement helper class to interpret the entries.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
