blob: b61bd3dfe34f303b7b10d9f1ffcb7f186181eaaa [file] [log] [blame]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<link rel="stylesheet" href="default_style.css">
<title>PDE - What's New in 3.2</title>
</head>
<body>
<h1><font size="4">What's New in 3.2</font></h1>
<p>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. </p>
<table border="0" cellpadding="10" cellspacing="0" width="80%">
<tr>
<td colspan="2">
<h2><font size="4">PDE</font></h2>
<hr>
</td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>Target definitions</b></p></td>
<td width="70%" valign="top">You can now define a target in a
.target file (<b>File &gt; New &gt; Other... &gt; Plug-in Development &gt; Target
Definition</b>).<p>The .target file defines all aspects of a target
including name, location, content (in terms of plug-ins, features, or both)
and JRE.</p>
<p>More notably, you can specify and manage multiple plug-in sites in the
target without the need for .link files.</p>
<p>The <b>Plug-in Development &gt; Target Platform</b> preference page lets you
browse, preview and apply existing target definitions.</p>
<p>
<img alt="screenshot" src="images/target_editor.png"></p></td>
</tr>
<tr>
<td colspan="2">
<hr></td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>Contributing targets</b></p></td>
<td width="70%" valign="top">Targets can be contributed to an
Eclipse product via the <b>org.eclipse.pde.core.targets</b> extension point.<p>
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.</p>
<p>
<img alt="screenshot" src="images/predefined_targets.png"></p></td>
</tr>
<tr>
<td colspan="2">
<hr></td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>Hierarchical view of plug-ins</b></p></td>
<td width="70%" valign="top">The plug-ins on the <b>Plug-in Development
&gt; Target Platform</b> preference page can now be grouped by sites. This
hierarchical view makes the management of large and distributed targets
much easier.
<p>
<img alt="screenshot" src="images/target_hierarchy.png"></p></td>
</tr>
<tr>
<td colspan="2">
<hr></td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>Plug-ins for any OSGi framework</b></td>
<td width="70%" valign="top">
The New Plug-in Project creation wizard (<b>File &gt; New &gt; Project...&gt;
Plug-in Project) </b>now provides the option to create plug-ins that can
run with any OSGi framework.&nbsp; A Hello OSGi template is also provided.<p>
<img alt="screenshot" src="images/equinox.png"></td>
</tr>
<tr>
<td colspan="2">
<hr>
</td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>Equinox OSGi framework launcher</b></p></td>
<td width="70%" valign="top">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.
<p>An Equinox OSGi framework launch configuration can
be created in the Launch Configuration dialog (<b>Run &gt; Run...</b> from
the top level menu).</p>
<p>
<img alt="screenshot" src="images/equinox_launcher.png"></p></td>
</tr>
<tr>
<td colspan="2">
<hr>
</td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>Java search hits in manifest files</b></p></td>
<td width="70%" valign="top">Searches for references to Java types and packages now reveal hits in
MANIFEST.MF, plugin.xml and fragment.xml files.<p>
<img alt="screenshot" src="images/pde_searchparticipant.png"></p></td>
</tr>
<tr>
<td colspan="2">
<hr>
</td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>Plug-in manifest files participate in refactoring</b></td>
<td width="70%" valign="top">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.</td>
</tr>
<tr>
<td colspan="2">
<hr>
</td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>NLS wizard for plug-in manifest files</b></p></td>
<td width="70%" valign="top">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.
<p>The wizard is available via <b>PDE Tools &gt; Externalize Strings...</b>
in the context menu of plug-in projects and their manifest files.</p>
<p><img alt="screenshot" src="images/nls.png"></p></td>
</tr>
<tr>
<td colspan="2">
<hr>
</td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>Organize plug-in manifest files</b></p></td>
<td width="70%" valign="top">The Organize Manifests wizard is
an appointment stop prior to shipping a plug-in.&nbsp; It removes unused
dependencies and property keys, and manages the exported packages ensuring
they are marked with the right visibility.<p>This function can be invoked via <b>PDE Tools &gt; Organize Manifests...</b>
from the context menu of plug-in projects and MANIFEST.MF files.</p>
<p>
<img alt="screenshot" src="images/organize_manifests.png"></p></td>
</tr>
<tr>
<td colspan="2">
<hr></td>
</tr>
<tr>
<td width="30%" valign="top" align="left"> <p align="right"><b>New processing instruction in plugin.xml files</b></p></td>
<td width="70%" valign="top">Plug-in manifest files generated by PDE now contain
a new processing instruction indicating version <b>3.2</b>, instead of <b>3.0</b>.
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.
<p>In the example below, the <i>org.eclipse.pde.core</i> plug-in contributes
an extension to the <i>org.eclipse.pde</i> namespace</p>
<p>
<img alt="screenshot" src="images/proc-instruction.png"></p>
<p>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.</p></td>
</tr>
<tr>
<td colspan="2">
<hr>
</td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>Bundle execution environment</b></p></td>
<td width="70%" valign="top">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.
<p>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 &gt;= 1.4.</p>
<p>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.</p>
<p>The <b>Execution Environments</b> section is on the <b>Overview</b> page
of the plug-in manifest editor.</p>
<p>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.&nbsp; Refer to the <b>Java &gt; Installed JREs &gt; Execution Environments</b>
preference page for a list of OSGi execution environments and the list of
installed JREs that are compatible with each.</p>
<p>
<img alt="screenshot" src="images/execution_environment.png"></p></td>
</tr>
<tr>
<td colspan="2">
<hr>
</td>
</tr>
<tr>
<td width="30%" align="left" valign="top"> <p align="right"><b>Automated management
of dependencies</b></p></td>
<td width="70%" valign="top">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.
<p>The <b>Automated Management of Dependencies</b> section on the <b> Dependencies</b>
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.</p>
<p>These dependencies do not get added to the MANIFEST.MF immediately, but
you can start coding right away as if they were.</p>
<p>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.</p>
<p>
<img alt="screenshot" src="images/dependency-mgmt.png"></p></td>
</tr>
<tr>
<td colspan="2"> <hr> </td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>Structural compare and syntax highlighting for manifest.mf files</b></p></td>
<td width="70%" valign="top">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.
<p>
<img alt="screenshot" src="images/manifest_compare.png"></p>
<p>Syntax highlighting has also been added to the MANIFEST.MF source page.
Colors and fonts preferences can be set on the <b>Plug-in Development &gt;
Editors</b> preference page.</p></td>
</tr>
<tr>
<td colspan="2">
<hr>
</td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>Validate build.properties files</b></p></td>
<td width="70%" valign="top">PDE now validates build.properties files to
flag potential problems that would prevent your plug-in from being exported
properly.<p>
<img alt="screenshot" src="images/build_properties_validation.png"></p><p>
The severity level for problems in build.properties files can be set on the
<b>Plug-in Development &gt; Compilers &gt; Plug-ins</b> preference page.</p><p>
<img alt="screenshot" src="images/validation_severity.png"></p></td>
</tr>
<tr>
<td colspan="2">
<hr></td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>Quick fixes for plug-in manifest files</b></p></td>
<td width="70%" valign="top">Quick fixes are now available for many types
of problems in MANIFEST.MF, plugin.xml and build.properties files, including:
<ul>
<li>unresolved type references</li>
<li>externalizing attributes and elements</li>
<li>replacement of deprecated attributes and directives</li>
</ul>
<p>
<img alt="screenshot" src="images/quickfix.png"></p></td>
</tr>
<tr>
<td colspan="2"> <hr> </td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>Automatic Javadoc attachment</b></td>
<td width="70%" valign="top">PDE now automates the task of attaching Javadoc
to libraries found on your plug-in's build path.<p>
<img alt="screenshot" src="images/javadoc.png"></p>
<p>Refer to the <b>org.eclipse.pde.core.javadoc</b> extension point documentation
for full details.</td>
</tr>
<tr>
<td colspan="2">
<hr>
</td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>New extension point schema editor</b></p></td>
<td width="70%" valign="top">The extension point schema editor has been redesigned.
New features include:
<ul>
<li>better visualization of the schema</li>
<li>simpler editing of attributes</li>
<li>drag and drop</li>
<li>inclusion of other schemas</li>
</ul>
<p>
<img alt="screenshot" src="images/new_schema.png"></p></td>
</tr>
<tr>
<td colspan="2">
<hr>
</td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>Headless RCP application template</b></td>
<td width="70%" valign="top">
The Eclipse runtime is a rich Java component model ideal for running
headless (non-UI) applications.<p>The New Plug-in Project creation wizard
(<b>File &gt; New &gt; Project...&gt; Plug-in Project) </b>now supports a workflow to
create headless RCP applications, complete with a Hello World template.</p>
<p>
<img alt="screenshot" src="images/headless.png"></p>
</td>
</tr>
<tr>
<td colspan="2">
<hr>
</td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>Form validation in product editor</b></p></td>
<td width="70%" valign="top">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.<p>
<img alt="screenshot" src="images/image_validation.png"></p>
</td>
</tr>
<tr>
<td colspan="2">
<hr>
</td>
</tr>
<tr>
<td width="30%" valign="top" align="left"> <p align="right"><b>Integrated progress monitor in product splash screen</b></p></td>
<td width="70%" valign="top">If you like the integrated progress bar in the
Eclipse splash screen, you can easily do the same for your product splash
screen.
<p>The <b>Branding</b> page of PDE product editor provides support to add
and customize an integrated progress bar. </p>
<p>
<img alt="screenshot" src="images/progress.png"></p></td>
</tr>
<tr>
<td colspan="2"> <hr> </td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>Platform-specific launcher arguments for cross-platform
product export</b></p></td>
<td width="70%" valign="top">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 &lt;launcher&gt;.ini files in a
single cross-platform export operation.<p>
<img alt="screenshot" src="images/launcher_ini.png"></p></td>
</tr>
<tr>
<td colspan="2">
<hr>
</td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>Add a Welcome page to your product</b></td>
<td width="70%" valign="top">A welcome page is your opportunity to provide a
pleasant initial user experience to your product.<p>The <b>Branding</b> page
of the product configuration editor (<b>File &gt; New &gt; Other...&gt; Product
Configuration</b>) now has a <b>Welcome Page</b> section, which will help
you create a template welcome page for your product.</p>
<p>
<img alt="screenshot" src="images/welcome.png"></td>
</tr>
<tr>
<td colspan="2">
<hr>
</td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>Sharable and portable PDE launch configurations</b></td>
<td width="70%" valign="top">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.</td>
</tr>
<tr>
<td colspan="2">
<hr>
</td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>Templates for launching arguments</b></p></td>
<td width="70%" valign="top">You can now specify a template for program and
VM arguments, which will be used to initialize default arguments on new PDE
launch configurations.<p>
<img alt="screenshot" src="images/launching.png"></p></td>
</tr>
<tr>
<td colspan="2">
<hr></td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>Enhanced and automatic plug-in validation prior to launching</b></p></td>
<td width="70%" valign="top">The <b>Validate Plug-in Set </b>functionality, available on the <b>
Plug-ins</b> tab of all PDE launchers, analyzes the list of selected
plug-ins to find lurking launching startup problems.&nbsp;
<p>This function has now been enhanced to forecast more types of
unsatisfied constraints that would prevent your plug-in from running.</p>
<p>You can also opt to have this validation done automatically prior to
every launch.</p>
<p>
<img alt="screenshot" src="images/autovalidation.png"></p></td>
</tr>
<tr>
<td colspan="2">
<hr>
</td>
</tr>
<tr>
<td width="30%" valign="top" align="left" height="19">
<p align="right"><b>New source lookup for debugging Eclipse applications</b></p></td>
<td width="70%" valign="top" height="19">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.
<p>The <b>Source</b> tab has been removed from the Eclipse/Equinox/Plug-in
JUnit launch configurations as it is no longer needed.</p></td>
</tr>
<tr>
<td colspan="2">
<hr></td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>Plug-in level custom Ant targets</b></p>
</td>
<td width="70%" valign="top">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.</td>
</tr>
<tr>
<td colspan="2">
<hr>
</td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>Building products</b></p></td>
<td width="70%" valign="top">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. </td>
</tr>
<tr>
<td colspan="2">
<hr>
</td>
</tr>
<tr>
<td width="30%" valign="top" align="left">
<p align="right"><b>Multiple repository support</b></p></td>
<td width="70%" valign="top">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 <b>org.eclipse.pde.build.fetchFactories</b>
extension point. PDE Build provides the standard extension for fetching
files from CVS.</td>
</tr>
<tr>
<td colspan="2">
<hr></td>
</tr>
</table>
</body>
</html>