1.0 Introduction
2.0 Known problems and limitations
2.1 Comments in source pages of PDE XML editors
2.2 Clipboard operations in the property view
2.3 Problem while importing fragments
2.4 Assumption that output is in bin/ folder
2.5 Preferences not working with import/export
2.6
Clipboard operations do not work in the Feature Manifest Editor
2.7
Choosing Compute Build Path causes Java project to no longer build
2.8
ECLIPSE_HOME produces fragile class paths due to version numbers in plug-in
directory paths
2.9
Plug-in import wizard does not allow plug-ins of different versions to be
imported
2.10 PDE nature required for plug-in manifest syntax checking
2.11 PDE does not preserve original manifest file layout
2.12
Go To Line in manifest editor causes Outline view to go blank
2.13
New Feature wizard does not generate build.properties file
2.14
Update Classpath attaches source from the wrong installation
2.15 No way to specify plug-in library type
2.16
Run-time libraries exported through more than 2 plug-ins not in classpath
2.17 PDE source page colors do not take effect on Apply
2.18 Icons folder not
included in bin.includes of some PDE templates
2.19 Emacs key bindings do not work in
manifest editor fields
This contains information on known problems and limitations with the plug-in development environment.
PDE provides a number of multi-page editors that include a raw source page. Editors that handle XML files (plug-in, fragment and feature manifests) will preserve comments in most cases. However, comments will not be preserved if added before the root XML element, or if added after the last child element contained in the parent element.
Clipboard shortcuts (Ctrl+X, Ctrl+C, Ctrl+V etc.) do not work in cell editors of properties that belong to the PDE Plug-in Manifest Editor. Use the pop-up menu to activate these operations.
If a workspace contains binary projects for a plug-in and a fragment that references that plug-in, fragment libraries are added to the class path of the referenced plug-in project. When an attempt is made to overwrite the plug-in and the fragment with versions from another build, deletion of the old fragment may fail. If that happens, repeat the operation to repair the workspace. Only the affected plug-in and fragment need to be re-imported.
PDE assumes that all plug-in and fragment projects that contain Java code have one or more source folders and build output in the bin/ folder. Although it is possible to change the name of the output folder in Properties dialog, the PDE run-time workbench launcher does not work correctly if you do that.
Preferences set in Target Platform PDE preference page are not preserved. Consequently, they are not subject to Import/Export operations in the Preferences dialog.
GUI pages of the Feature Manifest Editor support pop-up menus that contain standard clipboard operations (such as cut, copy, and paste). However, none of these operations work for structural widgets (trees and lists). The only place where these operations do work is in text widgets in the Information and Source pages.
PDE computes the build class path of a plug-in project by looking up source
mappings in the build.properties file. This file defines how source
folders are compiled into run-time libraries. In the absence of this file, PDE
will compute the class path that contains no source folders, resulting in
compilation errors. The required build.properties file is generated
by PDE when a new plug-in project is created. If the plug-in project is created
in some other way, a build.properties file must be added manually.
See the PDE Guide for details on the format of build.properties
files.
Eclipse products are typically built so that plug-ins are located in the same
directory and each plug-in is in the directory whose name includes both a
plug-in ID and a version ID (for example, "org.eclipse.ui_2.0.0").
If external plug-ins are used while self-hosting, these plug-in directory names
show up in PDE-generated class paths. These class path are sensitive to plug-in
version changes and must be recomputed if the target platform uses different
version numbers.
WebSphere Studio allows two plug-ins with the same ID but different versions to coexist if the only thing they contribute is run-time libraries. However, PDE cannot handle these plug-ins because it creates project names using plug-in IDs during binary project import.
PDE will only be able to provide syntax checking and error/warning markers for plug-in manifests if the plug-in project has the PDE plug-in nature. A plug-in project automatically gets this nature when created by a PDE wizard. This situation can only occur if a regular Java project has been used to host a plug-in. The problem can be fixed by converting it into a PDE project.
When non-Source page of a PDE manifest editor is used, PDE will convert changes back into XML by regenerating the file. Although the overall content and the comments are preserved, the actual file layout is not. This may cause problems by showing false changes during file compare. If file layout is important, perform all editing in the Source page. Alternatively, avoid using Source pages altogether. Since XML files are generated in a way that respects and preserves the relative order of major elements (extensions, extension points etc.), changes made in a non-Source page of a PDE manifest editor do not result in false deltas during file compare.
When the Source > Go To Line command is invoked in the Source page of a PDE manifest editor, the Outline view will become gray. Since the Source page does not have a functional outline, there is no actual loss of function.
When creating a new feature project, the PDE wizard does not automatically
generate a build.properties file. As a result, building the feature
will create a feature JAR without any content. To work around this, create a build.properties
manually using the instructions provided in the PDE Guide.
Java libraries are associated with source code according to source code locations specified in a PDE preference. By default, these locations are registered by plug-ins of the design-time WebSphere Studio instance. If the target platform is not the same as the design instance, the source code provided by these plug-ins will not be in sync with the libraries. The workaround is to uncheck the default locations and define new source code locations that point to the source-bearing plug-ins in the target WebSphere Studio installation.
PDE manifest editors do not provide widgets for specifying run-time library types as being either "code" or "resource". The only way to specify this attribute is to add it manually in the source page.
If a plug-in requires a runtime library exported through more than two
plug-ins, it is not automatically added to the compile class path when
generating the build.xml file. Example: Plug-in A export its
libraries, plug-in B requires plug-in A and re-exports A, plug-in C requires
plug-in B and re-exports B. If plug-in D requires plug-in C, when generating the
build.xml file, plug-in A libraries will not be added to the
compile path even though they will be available at runtime. The problem can be
worked around as follows::
- Generate a
build.xmlusing PDE (select theplugin.xmlfile and click Create Plug-in JARs)- Edit the
build.propertiesand add the following line:
custom = true- Add the missing JARs to the classpath of the javac task in
build.xml.
Changes to the colors PDE uses for source pages of its multi-page editors are not immediately visible in opened editors after pressing the Apply button on the Plug-in Development > Editors preference page. To work around this problem, close the editor and and reopen it.
PDE provides a number of templates that can be used to create fully
functioning plug-in projects and/or extensions. When projects are created, the
build.properties file is created with the initial content, which
includes the property 'bin.includes' listing the plug-in manifest and its code
JARs. However, it omits mention of other files created by the template, such as
the icons/ folder. As a request, these extra files do not end up in
the plug-in when built using Ant build file or exported using 'Export deployable
plug-ins and fragments' wizard. To work around this problem, add these files and
directories manually in build.properties file.
Non-default key bindings currently do not work in fields on non-source pages of the PDE manifest editors.
Return to the main readme file
(C) Copyright IBM Corporation 2000, 2003. All Rights Reserved.