Community
Participate
Working Groups
Build Identifier: 20100917-0705 I have a plugin that contains some binary jar files. These are correctly added to the Bundle-Classpath and should be part of the plugin when run through the launch configuration. Only the output class file directories are placed on the runtime classpath. I did some investigation into the PDE code to see where the problem lies. The ClasspathHelper class correctly looks through each library on the Bundle-Classpath to add them to the runtime path. The problem comes in when it looks at the JDT classpath. The 'getClasspathMap' method is used to find the actual jar to resolve the bundle classpath. This method though ignores all jar files (CP_LIBRARY) unless they are linked. This is causing the jars to not be added to dev.properties. The PDE launcher should respect the classpath defined by the manifest and include jar files even if they are not linked or the bundle ID is 'org.eclipse.osgi'. --- A sample testcase project is included as an attachment. Details are described below... Contents of Manifest.MF: Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Test-pde-project Bundle-SymbolicName: test-pde-project Bundle-Version: 1.0.0.qualifier Require-Bundle: org.eclipse.ui, org.eclipse.core.runtime Bundle-ClassPath: plugin-out.jar, lib/dummy.jar Contents of build.properties: source.plugin-out.jar = src/ output.. = bin/ bin.includes = META-INF/,\ plugin-out.jar,\ lib/dummy.jar plugin-out.jar is the output jar file that should be created from the source of the plugin. The dummy.jar file should also be included in the runtime classpath. Both of these should be in dev.properties when the PDE launches eclipse. This is what is actually generated in dev.properties: # #Wed Oct 06 10:11:09 ADT 2010 test-pde-project=bin @ignoredot@=true Reproducible: Always Steps to Reproduce: 1. Load the attached project. 2. Run the 'Eclipse Application' launcher from the configuration file. 3. Check .metadata\.plugins\org.eclipse.pde.core\Eclipse Application\dev.properties to see if it correctly included the jar files from the Bundle-Classpath.
Created attachment 180529 [details] Project Testcase
Created attachment 180675 [details] Patch to allow non linked libraries as part of the classpath Created a patch that removes the linking restriction on libraries on the classpath. This allows the testcase project to function properly.
This issue was originally reported against version 3.6.1. I have updated and attached a patch for version 3.7.
Created attachment 200832 [details] Patch for eclipse 3.7
We have currently the same problem. JAR files are added into the classpath of the plugin, but when starting the product it fails with a NoClassDefFoundException. Is there a workaround for this problem?
Fixed in master: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=b99906645b684060122828ac25a7c65bba6e30dc Thanks for the contribution Chris! The fix works as expected, allowing non-linked jars to be added to the dev classpath. I don't know why this was a restriction in the first place (it's been this way for 5 years).
Verified I20120808-2000
since the switch to 4.3.0 as IDE (!) we have a problem with our application (same target platform as before the switch (Eclipse 3.8.0)): We have a MANIFEST.MF doing this: Bundle-ClassPath: ., lib/slf4j-log4j12-1.6.1.jar, lib/mail.jar, lib/jul-to-log4j-20090813.jar, lib/log4j-component-20090813.jar, lib/log4j-extras-20090813.jar, lib/slf4j-api-1.6.1.jar Now, all classpath entries appear TWICE when launching from the IDE. We debugged a little, and discovered that when adding "." to the classpath (in org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassPathEntry), the org.eclipse.osgi.internal.baseadaptor.DevClassLoadingHook adds too many classpath entries. it adds not only ".", but finds all the jar files also. After this, the jar files are added /again/ from org.eclipse.osgi.baseadaptor.loader.ClasspathManager.addClassPathEntry (also called from findClassPathEntry). I think the previous "fix" from this bug is the cause of the problem. In our scenario this means that slf4j gets on the classpath twice, yielding this: SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [bundleresource://64.fwk175408781:6/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [bundleresource://64.fwk175408781:13/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. I think there is more to do .... can somebody please reopen?
(In reply to Markus Duft from comment #8) > I think there is more to do .... can somebody please reopen? Opened Bug 417869 to track this regression. If at all possible, take a crack at providing a fix.
i fear it's not really possible :| i already tried to understand what is going on in the classpath manager, but it seems a little cryptic to me :/ maybe i find time to take another look, but i'd really appreciate if an expert takes care of the problem ;)
