Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Pragmatic Advice on PDE Classpath"

Line 10: Line 10:
 
# Launch Configuration.
 
# Launch Configuration.
 
Unless you know what you are doing, the first thing to do is make
 
Unless you know what you are doing, the first thing to do is make
sure that you only use MANIFEST.MF.  In particular the ''Configure Build Path'' has to be cleared out of anything you put in there because it is only seen at compile time.
+
sure that you '''only use MANIFEST.MF'''.  In particular, '''do not use ''Configure Build Path'' ''',
 +
indeed, it has to be cleared out of anything you put in there because it is only seen at compile time.
  
 
In the MANIFEST.MF systematically try to use Dependencies->RequiredPlugins and  
 
In the MANIFEST.MF systematically try to use Dependencies->RequiredPlugins and  
Line 21: Line 22:
 
and "Open Declaration" on the method or field.  Then use the little double arrow
 
and "Open Declaration" on the method or field.  Then use the little double arrow
 
thingy on Package Explorer to sync the package view to the method.  That will tell you what lib/plugin is bound at compile time.  Then you need
 
thingy on Package Explorer to sync the package view to the method.  That will tell you what lib/plugin is bound at compile time.  Then you need
to run the debugger to the line and figure out why that lib/plugin is not on the path.
+
to run the debugger to the same line and figure out why that lib/plugin is not on the path at run-time.
  
 
== See Also ==
 
== See Also ==
 
*[[FAQ What is the classpath of a plug-in?]]
 
*[[FAQ What is the classpath of a plug-in?]]
 
*[http://www.eclipse.org/articles/Article-PDE-does-plugins/PDE-intro.html PDE Does Plug-ins]
 
*[http://www.eclipse.org/articles/Article-PDE-does-plugins/PDE-intro.html PDE Does Plug-ins]

Revision as of 13:39, 30 January 2007

Here are some suggestions if you have plug-in code that compiles (classes found) but fails at runtime with class not found. There are at least three different classpaths:

  1. compile time
  2. runtime
  3. source code at debug

There are at least four different places these are controlled:

  1. MANIFEST.MF
  2. Preferences PDE Target Platform
  3. Project Right click Build Path Configure Build Path
  4. Launch Configuration.

Unless you know what you are doing, the first thing to do is make sure that you only use MANIFEST.MF. In particular, do not use Configure Build Path , indeed, it has to be cleared out of anything you put in there because it is only seen at compile time.

In the MANIFEST.MF systematically try to use Dependencies->RequiredPlugins and avoid Runtime->Classpath for anything other than classes for your plugin. (The theoretical best solution is to use "ImportedPackages" but its not clear to me what this thing does in practice.)

If you still have trouble, go in to the source at the where you have the runtime problem and "Open Declaration" on the method or field. Then use the little double arrow thingy on Package Explorer to sync the package view to the method. That will tell you what lib/plugin is bound at compile time. Then you need to run the debugger to the same line and figure out why that lib/plugin is not on the path at run-time.

See Also

Copyright © Eclipse Foundation, Inc. All Rights Reserved.