Community
Participate
Working Groups
Created attachment 249208 [details] Zip containing Eclipse projects that reproduce the bug. OVERVIEW: The Manifest Editor's "Automated Management of Dependencies" section does not always detect a required Imported Package. This results in a bundle with incorrectly specified Imported Packages that at runtime causes a java.lang.NoClassDefFoundError being thrown. When using a tool such as PDE this should NEVER happen. java.lang.NoClassDefFoundError: com/sas/dt/api/data/IProvider at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2493) at java.lang.Class.getConstructor0(Class.java:2803) at java.lang.Class.newInstance(Class.java:345) at org.eclipse.equinox.internal.ds.model.ServiceComponent.createInstance(ServiceComponent.java:493) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.createInstance(ServiceComponentProp.java:270) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:331) at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:620) at org.eclipse.equinox.internal.ds.ServiceReg.getService(ServiceReg.java:53) at org.eclipse.osgi.internal.serviceregistry.ServiceFactoryUse$1.run(ServiceFactoryUse.java:212) SIDEBAR: The Manifest Editor's "Automated Management of Dependencies" is not well understood by many PDE users, so here's a brief summary of how it is intended to be used: 1. A bundle's runtime dependencies (either Import-Package or Require-Bundle manifest header) may be calculated automatically by the Manifest Editor's "Automated Management of Dependencies" section of the the "Dependencies" tab. It should never be necessary to manually add dependencies. 2. Start by adding candidate bundle dependencies to the "Automated Management of Dependencies" list. This list extends the project's build path and has no direct bearing upon the bundle's runtime dependencies. 3. Having implemented the bundle's behavior such that there are no compiler errors, save all editors and return to the Manifest Editor's "Dependencies Page". It's time to compute the bundle's runtime dependencies. 4. Below the "Automated Management of Dependencies" list is the text that reads "Analyze code and add dependencies to the MANIFEST.MF via:" followed by two radio buttons, the first labeled "Require-Bundle", the second labeled "Import-Package". Choose the "Import-Package" radio button, which is my preferred way to express dependencies, and it's recommended by the OSGi specification. 5. Next, click the link "add dependencies" link above the radio buttons. Upon clicking the link the bundle's runtime dependencies are analyzed and the "Imported Packages" list is populated. 6. Save the Manifest Editor. 7. Additionally, you may right click in the "Imported Package" list and choose "Find unused dependencies" to re-compute the bundle's runtime dependencies and remove those that are unnecessary. Alternatively, you can simply manually delete the contents of the "Imported Packages" list and r-ecompute the bundle's runtime dependencies by clicking the "add dependencies" link again. So there you have it: How to manage bundle dependencies without having to guess. This approach clearly separates the task of defining a bundle's compile time build path as required by Eclipse, and computing the bundle's runtime dependencies as required by OSGi. Relying upon this behavior of PDE is critical when developing an application built from many projects/bundles. PROBLEM DESCRIPTION: Sometimes the computation of a bundle's dependencies is NOT accurately calculated. The test case that reproduces this problem is not easy to create, but I have captured the problem based on real code that I have trimmed as much as possible while still exhibiting the problem. TEST CASE: The attached test case contains the following Eclipse projects/bundles: 1. com.sas.dt.advisor 2. com.sas.dt.api 3. com.sas.dt.api.util 4. com.sas.dt.data 5. com.sas.dt.data.depot 6. com.sas.dt.skureq 7. com.sas.dt.tool 8. com.sas.dt.util 9. com.sas.dt.util.collector Unzip the attachd zip and import the projects into an Eclipse 4.4 (Luna) workspace. Bundle 7, com.sas.dt.tool, contains an OSGi.launch file that is the launch configuration that demonstrates the problem. Running this launch results in a failure in Bundle 1, com.sas.dt.advisor, as follows: java.lang.NoClassDefFoundError: com/sas/dt/api/data/IProvider. The "fix" is to manually add the package "com.sas.dt.api.data" to the com.sas.dt.advior bundle's Import-Package list. Upon doing so the OSGi.launch should work with nothing on the console, and the following bundles and DS components: osgi> ss "Framework is launched." id State Bundle 0 ACTIVE org.eclipse.osgi_3.10.0.v20140513-1456 1 ACTIVE com.sas.dt.api_1.0.0.qualifier 2 ACTIVE com.sas.dt.util_1.0.0.qualifier 3 ACTIVE org.eclipse.equinox.util_1.0.500.v20130404-1337 4 ACTIVE com.sas.dt.api.util_1.0.0.qualifier 5 ACTIVE org.eclipse.equinox.console_1.1.0.v20140131-1639 6 ACTIVE org.apache.felix.gogo.shell_0.10.0.v201212101605 7 ACTIVE com.sas.dt.data_1.0.0.qualifier 8 ACTIVE com.sas.dt.advisor_1.0.0.qualifier 9 ACTIVE org.apache.felix.gogo.command_0.10.0.v201209301215 10 ACTIVE com.sas.dt.data.depot_1.0.0.qualifier 11 ACTIVE com.sas.dt.skureq_1.0.0.qualifier 12 ACTIVE com.sas.dt.util.collector_1.0.0.qualifier 13 ACTIVE org.apache.felix.gogo.runtime_0.10.0.v201209301036 14 ACTIVE com.sas.dt.tool_1.0.0.qualifier 15 ACTIVE org.eclipse.equinox.ds_1.4.200.v20131126-2331 16 ACTIVE org.eclipse.osgi.services_3.4.0.v20140312-2051 osgi> list All Components: ID State Component Name Located in bundle 1 Registered com.sas.dt.util.xml.XmlParser com.sas.dt.util(bid=2) 2 Active com.sas.dt.internal.advisor.ProductDefinitionAdvisor com.sas.dt.advisor(bid=8) 3 Active com.sas.dt.internal.data.depot.DepotDataSourceProvider com.sas.dt.data.depot(bid=10) 4 Active com.sas.dt.internal.skureq.SkuRequirementsProvider com.sas.dt.skureq(bid=11) 5 Active com.sas.dt.internal.tool.DeployTool com.sas.dt.tool(bid=14) osgi> It should NOT be necessary to manually edit a bundle's Import-Package list! The right answer is that this dependency should have been computed by the PDE's "Automated Management of Dependencies" capability. If you use the "Find Unused Dependencies" menu option you'll see that the PDE thinks that "com.sas.dt.api.data" is an unused dependency, which is INCORRECT since removing it results in java.lang.NoClassDefFoundError: com/sas/dt/api/data/IProvider being thrown.
Created attachment 249209 [details] Equinox console output that when Import-Package is missing.
The package is being used through declarative services. I don't think the automated dependency management has any capabilities to check for that kind of usage. I'm not certain how much work it would be to add support for this, but it won't be trivial.
Thanks Curtis for taking a look. My hope is that the attached sample will be enlightening. Using DS is very well established at this point, so I'm hoping that this bug will be prioritized accordingly. I cannot imagine not using DS for my development of modular Java software, whether it's deployed using OSGi or not. I understand that it might be complicated. Of course without support for this scenario the PDE will lose ground to competing tools.
PDE does not have the resources to keep up with the state of DS tooling, but we will keep it in consideration for 4.5
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This bug has been marked as stalebug a while ago without any further interaction. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard flag.
This bug was marked as stalebug a while ago. Marking as worksforme. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag.
