Plug-in Development Environment (PDE)

The Plug-in Development Environment (PDE) provides tools to create, develop, test, debug, build and deploy Eclipse plug-ins, fragments, features, update sites and RCP products.
PDE also provides comprehensive OSGi tooling, which makes it an ideal environment for component programming, not just Eclipse plug-in development.
In PDE we do tooling, but our business is people!

		Download PDE ships with the Eclipse SDK and can be downloaded from the Eclipse project downloads page.
		Support Find support and interact with users and developers.
		Contributing to PDE The development of PDE is driven by the community in a transparent manner. Read our contributor guide wiki page and get involved.
		Wiki Visit the wiki page for release planning, test plans, user guides and more.

PDE Components

The PDE subproject is broken down into three main components, Build, UI and API Tools. We also have an Incubator component where we can develop non-SDK features.

Name	Description
PDE Build	Ant based tools and scripts to automate build processes
PDE UI	Models, builders, editors and more to faciliate plug-in development in the Eclipse IDE.
PDE API Tools	Eclipse IDE and build process integrated tooling to maintain API
PDE Incubator	Development of new tools that are not ready to be added to the Eclipse SDK

PDE Build

The goal of PDE Build is to facilitate the automation of plug-in build processes. Essentially, PDE Build produces Ant scripts based on development-time information provided by, for example, the plugin.xml and build.properties files. The generated Ant scripts, can fetch the relevant projects from a CVS repository, build jars, Javadoc, source zips, put everything together in a format ready to ship and send it out to a remote location (e.g., a local network or a downloads server).

PDE UI

The PDE UI component provides a comprehensive set of tools to create, develop, test, debug and deploy Eclipse plug-ins, fragments, features, update sites and RCP products.
PDE UI also provides comprehensive OSGi tooling, which makes it an ideal environment for component programming, not just Eclipse plug-in development.
Here is a small list of what PDE UI provides to the Eclipse SDK:

• Form-Based Manifest Editors - multi-page editors that centrally manage all manifest files of a plug-in or feature.
• RCP Tools - wizards and a form-based editor that allow you to define, brand, test and export products to multiple platforms.
• New Project Creation Wizards - create a new plug-in, fragment, feature, feature patch and update sites.
• Import Wizards - import plug-ins and features from the file system.
• Export Wizards - wizards that build, package and export plug-ins, fragments and products with a single click.
• Launchers - test and debug Eclipse applications and OSGi bundles.
• Views - PDE provides views that help plug-in developers inspect different aspects of their development environment.
• Miscellaneous Tools - wizards to externalize and clean up manifest files.
• Conversion Tools - wizard to convert a plain Java project or plain JARs into a plug-in project.
• Integration with JDT - plug-in manifest files participate in Java search and refactoring.
• User Assistance Tools - Editors and tools for developing user help and other UA documents.
• Declarative Services Tools - Editors and validation for OSGi declarative services.

PDE API Tools

API tooling will assist developers in API maintenance by reporting API defects such as binary incompatibilities, incorrect plug-in version numbers, missing or incorrect @since tags, and usage of non-API code between plug-ins. The tooling will be integrated in the Eclipse SDK and will be used in the automated build process.
Specifically, the tooling is designed to do the following:

• Identify binary compatibility issues between two versions of a software component or product.
• Update version numbers for plug-ins (bundles) based on the Eclipse versioning scheme.
• Update @since tags for newly added classes, interfaces, methods, etc.
• Provide new javadoc tags and code assist to annotate types with special restrictions.
• Leverage existing information (in MANIFEST.MF) to define the visibility of packages between bundles.
• Identify usage of non-API code between plug-ins.
• Identity leakage of non-API types into API.