By default, PDE updates the build path of a plug-in project every time you change the list of dependencies in the manifest editor. If you turn off that feature on the Plug-in Development->Java Build Path Control preference page, you will have to be responsible for updating the build path every time you make a change to the list of dependencies.
You are not required to use PDE's manifest editor to take advantage of PDE's build path computation feature. You can always use the Update Classpath... pop-up menu item available on all plugin.xml/fragment.xml files and Java plug-in projects to explicitly update the build path of your plug-in. This will cause a wizard to open:
The checkbox list will contain all the plug-ins and fragments in the workspace. Select the plug-ins/fragments whose build path you wish to update and press 'Finish'.
Note that when computing the build path, PDE recreates it from scratch. That means that you will lose any entries you have added manually to the build path. The build path is updated from scratch because PDE builds it recursively. Here's why:
If a Java class is referenced by a plug-in at run time, its libraries will be searched first for the class, then the libraries of its required plug-ins, then the libraries of their required plug-ins, and so on. In order to recreate a similar lookup environment during design time, PDE updates the build path recursively. It is possible for several different plug-ins to depend on the same library. If you delete one of these plug-ins from your dependency list, it is not safe to remove libraries all the way up the chain because some of the plug-ins you still have on the list may be needing them. The only way to always maintain a valid build path is to create it from scratch.
In order to provide for better sharing of projects on authoring servers, PDE adds all external libraries to the build path relative to the run-time platform location represented by 1 or more Java classpath variables whose suffix is ECLIPSE_HOME. This way, you can have your code on the server and it will work regardless of the location of your platform install. These variables are set and managed by PDE and you are not supposed to modify their values.
Since 2.1, PDE provides an alternative way of expressing and computing the classpath. Instead of explicitly creating the entries for the dependent plug-ins, it introduces a level of indirection using JDT classpath container. The container replaces all the dependent plug-in entries and provides for a stable and predictable classpath. When using classpath container, your classpath will contain source folder(s), required plug-ins container, and JRE container (uses identical mechanism to provide a proxy for the real JRE entries that are computed on the fly). You can share this classpath on the server without worry that it will cause problems on other developers' machines and/or operating systems.
In order to use classpath containers, all that is needed is to open Preferences>Plug-in Development>Java build path control and select 'Use classpath containers...' checkbox. You will need to update classpaths of your project in order to see the changes applied. Once you switch to classpath containers, you can use either external plug-ins or import binary plug-in projects, or a mix of both. Whatever you do, classpath container will keep up with the changes and adapt.