Community
Participate
Working Groups
When moving our plug-in projects to Eclipse 3.0 M6 (using M6 as our development environment)we are forced to add org.eclipse.osgi to many of our plug-in projects because the project will not build due to an indirect reference to org.osgi.framework.BundleActivator. We should not be required to add a plug-in dependency to get the project to build when we do not have a direct reference. This is forcing us to add dependencies that don't actually exist during runtime.
Does this happen when you are trying to export or when you are developing against M6 and your plugins are loaded into the workspace?
During development and not export.
If you think that your code should compile without osgi explicitly being on the classpath, then this is a compiler issue that should be taken up with JDT Core.
I am expecting that osgi should be on the classpath but I should not have to modify my plug-in dependencies to add it explicitly just for build purposes. It will run just fine without the dependency but it will not build. I think the Plug-in Dependencies classpath container should resolve to indirectly referenced plug-ins as well as those that are directly referenced. John Weigand told me this is how it was supposed to work.
Please provide reproduceable steps for further action. We did fix such an issue before M6, there maybe another instance of this, where the compiler is a not lazy enough (would force to load more types to perform some check). Things you could try is to disable some optional warnings to see if these are inducing these extra requirements. Please reopen once steps are available.
Here is a very simple scenario: 1. Check out org.eclipse.pde.runtime from CVS. 2. Open the dependencies page. Remove core.runtime.compatibility and add a dependency on org.eclipse.core.runtime. 3. Save. The classpath will automatically update and you will get compiler error complaining that some osgi bundleactivator class is indirectly referenced and cannot be found on the classpath. Is this a JDT core bug, or should core.runtime reexports its dependencies? cc'ing Jeff.
Re comment #4, after the switch to the OSGi runtime, PDE does not and must not add any plug-ins for free. So unless org.eclipse.core.runtime reexports its dependencies, PDE will not add them to your plug-in's classpath.
Reproduced. Comment #6 steps can be reproduced in a simpler way by removing the PDE container, and adding instead direct project references to: - org.eclipse.core.runtime - org.eclipse.ui - org.eclipse.ui.views Offending problems: - The project was not built since its build path is incomplete. Cannot find the class file for org.osgi.framework.BundleActivator. Fix the build path then try rebuilding this project. - IHelpContextIds.java / The type org.osgi.framework.BundleActivator cannot be resolved. It is indirectly referenced from required .class files.
Problem occurs when resolving hierarchy of type: /org.eclipse.pde.runtime/src/org/eclipse/pde/internal/runtime/PDERuntimePlugin.j ava
It is curious that the problem is reported against the wrong type in the end.
The supertype chain of PDERuntimePlugin is referencing an osgi type, which cannot be made private to plugin implementors. PDERuntimePlugin --> AbstractUIPlugin --> Plugin --> BundleActivator Problem is in Core/Runtime which either should reexport osgi (sounds like unwanted) or clear this dependency (encapsulate osgi concerns).
Dan is right that he should not have to change his plugin. There was a problem in the runtime dependencies (we overlooked something). I believe that this problem is fixed in today's integration build. The plan is for the runtime plugin to require and reexport the osgi bundle. Thus, anyone who gets runtime will get osgi. PDE should not have to change at all since it will just see more prerequisites. I'll leave this open until Dan is happy.
I forgot to mention, I released a fix in the compiler so that it should flag the problem against the right type, and thus avoid confusing the user. Jeff - does this mean that people are allowed to code against OSGi directly ? If you reexport it, you are granting access to anybody downstream.
yup. there was never any intention to hide the OSGi layer. People could import the packages previously. We observed however that that required them to make a manifest.mf rather than a plugin.xml. That is a bit painful and counter to the provide/requires mechanism so we now have the OSGi bundle provide its packages as well as export them. So, is this bug fixed?
Latest compiler now blames PDERuntimePlugin as expected.
We believe this is fixed. Re-open if you still see an issue.
