## What's New in 3.2

This document contains descriptions of some of the more interesting or significant changes made to PDE for the 3.2 release of Eclipse since 3.1.

## PDE
Target definitions | You can now define a target in a .target file (File > New > Other... > Plug-in Development > Target Definition). The .target file defines all aspects of a target including name, location, content (in terms of plug-ins, features, or both) and JRE. More notably, you can specify and manage multiple plug-in sites in the target without the need for .link files. The Plug-in Development > Target Platform preference page lets you browse, preview and apply existing target definitions.
Contributing targets | Targets can be contributed to an Eclipse product via the org.eclipse.pde.core.targets extension point. The Eclipse SDK comes with two RCP-centric org.eclipse.pde.core.targets extensions, allowing you to easily switch the target platform back and forth between the SDK and the RCP subset.
Hierarchical view of plug-ins | The plug-ins on the Plug-in Development > Target Platform preference page can now be grouped by sites. This hierarchical view makes the management of large and distributed targets much easier.
Plug-ins for any OSGi framework | The New Plug-in Project creation wizard (File > New > Project...> Plug-in Project) now provides the option to create plug-ins that can run with any OSGi framework. A Hello OSGi template is also provided.
Equinox OSGi framework launcher | A new launcher is now available to run and debug bundles with the Equinox OSGi framework. You will be able to set the start level of your bundles and customize program and VM arguments to test your bundles under different conditions. An Equinox OSGi framework launch configuration can be created in the Launch Configuration dialog (Run > Run... from the top level menu).
Java search hits in manifest files | Searches for references to Java types and packages now reveal hits in MANIFEST.MF, plugin.xml and fragment.xml files.
Plug-in manifest files participate in refactoring | When you move or rename a Java type or package in your plug-in, PDE now automatically updates all references to these types and packages in the manifest files of the affected plug-ins.
NLS wizard for plug-in manifest files | PDE now provides a wizard to extract translatable strings from plug-in manifest files and store them in a properties files for multi-language support. The wizard is available via PDE Tools > Externalize Strings... in the context menu of plug-in projects and their manifest files.
Organize plug-in manifest files | The Organize Manifests wizard is an appointment stop prior to shipping a plug-in. It removes unused dependencies and property keys, and manages the exported packages ensuring they are marked with the right visibility. This function can be invoked via PDE Tools > Organize Manifests... from the context menu of plug-in projects and MANIFEST.MF files.
New processing instruction in plugin.xml files | Plug-in manifest files generated by PDE now contain a new processing instruction indicating version 3.2, instead of 3.0. This new processing instruction is required if a plug-in is to take advantage of the new runtime support where a plug-in can contribute extension points and extensions to a namespace other than its own. In the example below, the org.eclipse.pde.core plug-in contributes an extension to the org.eclipse.pde namespace Note that there is no need to migrate an existing plug-in to use the new processing instruction unless you want to use the new namespace support in that plug-in.
Bundle execution environment | A bundle execution environment specifies the minimum level of JRE required for the plug-in to run. If the JRE used to run Eclipse does not meet the requirement, the plug-in will not run. If you declare J2SE-1.4 as your plug-in's bundle execution environment, for example, your plug-in will run with a JRE version >= 1.4. If the plug-in can run in execution environments that are not proper subsets of each other (e.g J2SE-1.4 and CDC-1.1/Foundation-1.1), then all such bundle execution environments should be listed. The Execution Environments section is on the Overview page of the plug-in manifest editor. During a plug-in export, the plug-in code is compiled against the JRE associated with the first execution environment listed in the MANIFEST.MF. Refer to the Java > Installed JREs > Execution Environments preference page for a list of OSGi execution environments and the list of installed JREs that are compatible with each.
Automated management of dependencies | PDE now provides a new flexible workflow that allows you to code your plug-in first, and then have your code analyzed, and the list of plug-in dependencies automatically generated for you by PDE after. The Automated Management of Dependencies section on the Dependencies page of the plug-in manifest editor lets you specify a list of plug-ins that you wish to augment your development build path (and hence your content assist scope) with. These dependencies do not get added to the MANIFEST.MF immediately, but you can start coding right away as if they were. At any time, you can tell PDE to analyze your code and generate the correct dependencies in your MANIFEST.MF via either the Require-Bundle or Import-Package headers.
Structural compare and syntax highlighting for manifest.mf files | When comparing two versions of a bundle MANIFEST.MF file, the new structure compare viewer will let you easily see what headers have been added, removed or modified. Syntax highlighting has also been added to the MANIFEST.MF source page. Colors and fonts preferences can be set on the Plug-in Development > Editors preference page.
Validate build.properties files | PDE now validates build.properties files to flag potential problems that would prevent your plug-in from being exported properly. The severity level for problems in build.properties files can be set on the Plug-in Development > Compilers > Plug-ins preference page.
Quick fixes for plug-in manifest files | Quick fixes are now available for many types of problems in MANIFEST.MF, plugin.xml and build.properties files, including: unresolved type references externalizing attributes and elements replacement of deprecated attributes and directives
Automatic Javadoc attachment | PDE now automates the task of attaching Javadoc to libraries found on your plug-in's build path. Refer to the org.eclipse.pde.core.javadoc extension point documentation for full details.
New extension point schema editor | The extension point schema editor has been redesigned. New features include: better visualization of the schema simpler editing of attributes drag and drop inclusion of other schemas
Headless RCP application template | The Eclipse runtime is a rich Java component model ideal for running headless (non-UI) applications. The New Plug-in Project creation wizard (File > New > Project...> Plug-in Project) now supports a workflow to create headless RCP applications, complete with a Hello World template.
Form validation in product editor | The product editor now reports warnings and errors in the title area of each page. Problems reported include invalid paths and the wrong size and depth of an image.
Integrated progress monitor in product splash screen | If you like the integrated progress bar in the Eclipse splash screen, you can easily do the same for your product splash screen. The Branding page of PDE product editor provides support to add and customize an integrated progress bar.
Platform-specific launcher arguments for cross-platform product export | In the product editor, it is now possible to specify platform-specific program and VM arguments to launch a product with. This allows the creation of platform-specific <launcher>.ini files in a single cross-platform export operation.
Add a Welcome page to your product | A welcome page is your opportunity to provide a pleasant initial user experience to your product. The Branding page of the product configuration editor (File > New > Other...> Product Configuration) now has a Welcome Page section, which will help you create a template welcome page for your product.
Sharable and portable PDE launch configurations | The PDE launch configurations (Eclipse Application and Plug-in JUnit) now support variable substitutions. Careful use of variables allows the saved form of the launch configuration to be portable across operating systems and sharable across teams.
Templates for launching arguments | You can now specify a template for program and VM arguments, which will be used to initialize default arguments on new PDE launch configurations.
Enhanced and automatic plug-in validation prior to launching | The Validate Plug-in Set functionality, available on the Plug-ins tab of all PDE launchers, analyzes the list of selected plug-ins to find lurking launching startup problems. This function has now been enhanced to forecast more types of unsatisfied constraints that would prevent your plug-in from running. You can also opt to have this validation done automatically prior to every launch.
New source lookup for debugging Eclipse applications | When debugging Eclipse applications, PDE now uses a custom source lookup mechanism that is tied to the OSGi class loader. This is both faster and more accurate than the standard linear Java source lookup. The Source tab has been removed from the Eclipse/Equinox/Plug-in JUnit launch configurations as it is no longer needed.
Plug-in level custom Ant targets | The generated build.xml for a plug-in now supports custom targets at the plug-in level. Set the property "customBuildCallbacks" in a plug-in's build.properties file to point at an Ant script and pre and/or post ant calls will be generated for the following targets: build.jars, build.sources, the compilation target (eq: @dot), gather.bin.parts, gather.sources, gather.logs, and clean. In many cases these custom callbacks can be used instead of having an entirely custom build.xml. A template customBuildCallbacks.xml is provided in org.eclipse.pde.build/templates.
Building products | PDE Build now supports building products from a .product file in a headless automated build. A feature will be automatically generated based on the contents of the product file.
Multiple repository support | The PDE Build generation of fetch scripts for headless builds is now extensible. Extenders may contribute support for fetching elements from additional repositories through the org.eclipse.pde.build.fetchFactories extension point. PDE Build provides the standard extension for fetching files from CVS.