Community
Participate
Working Groups
The recent introduction of version numbers in plug-in subdirectories has created a serious problem for projects using ECLIPSE_HOME to reference a JAR in a plug-in. E.g., the build classpath entry used to resemble ECLIPSE_HOME/plugins/org.eclipse.core.runtime/runtime.jar and now it necessarily looks like ECLIPSE_HOME/plugins/org.eclipse.core.runtime_2.0.0/runtime.jar The workaround is to use the PDE import plug-ins to create binary library projects and to convert the build classpath entry to a required project. This is just a workaround, however. We do *not* want to force every plug-in developer to use required projects and binary library projects.
Classpath is now cheap to recompute thanks to the 'Update Classpath' wizard in the Navigator/Packages. I agree that having a hard-coded version in the path may be a problem, but I have not solution at the moment. As a side note, our mapping of plug-in dependencies to classpath is crude either way. We do not have a way of expressing full dependency constraints (those that use versions and match rules in addition to IDs) either using ECLIPSE_HOME or project references. The described problem actually introduces an 'EXACT' match constraint for plug-ins that do not have it. One solution would be to stop using one variable and use variable per plug-in i.e. instead of ECLIPSE_HOME/plugins/org.eclipse.core.runtime/runtime.jar, we have ORG_ECLIPSE_CORE_RUNTIME/runtime.jar. This will test variable system scalability (i.e. 160+variables for WSAD :-). I don't know if we want to do this.
from jbbriaud@sysdeo.com : automatic computation of classpath doesn't seem to solve problem. Using CVS to share code between developpers that have the *same* build of Eclipse lead to classpath problem if project is a plugin project. workaround : supress and reassign at least one plugin dependancie after having reload plugin in the preference/pde dialog box.
from jbbriaud@sysdeo.com : automatic computation of classpath doesn't seem to solve problem. Using CVS to share code between developpers that have the *same* build of Eclipse lead to classpath problem if project is a plugin project. workaround : supress and reassign at least one plugin dependancie after having reload plugin in the preference/pde dialog box. This could be done between workspaces in the same machine with CVS checkout.
PDE now supports dynamic classpath computation using classpath containers. To activate it: 1) Turn it on in PDE Preferences->Use classpath containers 2) Recompute classpaths of all your projects You will get all the entries for dependent plug-ins replaced with one classpath container entry. This entry will be dynamically computed when needed. It will follow changes in your workspace and switch from external JARs to project references depending on whether the plug-ins are in the workspace (as projects) or outside (in the target platform). For plug-ins in the target platform (outside) we recommend using PDE 'Plugins' view to get the 'Navigator' experience (for browsing the structure, opening files). You can also copy or drag'n'drop files form the view into the Navigator or Package Explorer.
