You can then enter OSGi commands into the console to interact directly with the framework running the IDE.

Spell checking is now available in the Table of Contents (TOC) and Context Help editors.

Features from both the workspace and the target can be included. Individual plug-ins can be added to the launch to include plug-ins that are not part of a feature. PDE will launch all the selected plug-ins as well as all required plug-ins.

Features in the workspace are used over external features, however, this can be configured by un-checking 'Use features from workspace if available'. Bundles in the workspace are used over external bundles in the target platform. However, this can be configured by modifying the configuration's default bundle resolution policy, or can be configured per feature using the cell editors in the 'Plug-in Location' column.

The second page allows you to choose from all bundles with source repository information. Select the bundles you want to import and press Next.

The last page of the wizard allows you to import the specific versions of the bundles used in the target platform or from HEAD. Pressing Finish will import the projects into your workspace.

You can also import projects from the Plug-ins view. Use the Import As > Project from a Repository... action to import plug-ins from CVS.

Note: This will copy all features and plug-ins that are part of your currently set target platform to the destination directory.

Java search operations are scoped to workspace projects and their dependencies. Developers don't typically have the entire target platform in their workspace and thus Java search operations don't locate references from many upstream plug-ins. You can manually add plug-ins to the Java search path using the Add All Plug-ins to Java Search action in the Plug-ins view. However, the new preference automatically keeps the search path in synch with the target platform.

Under the covers a project named External Plug-in Libraries is created with all external plug-ins in the target platform on its build path.

You can generate reports describing what API and internals are being used by other bundles. API use reports have been integrated as an external tool (Run > External Tools > External Tool Configurations...). For example, the following report settings are used to generate a report revealing which internal components of the debug platform are being consumed by JDT.

A report is run against a set of bundles which can be specified as an API baseline, a target definition or a directory of bundles. You can search for API and/or internal references and you can limit the report to specific bundles by using regular expressions. You must specify an output location (directory) for the report and whether to generate HTML.

Package exports in bundle manifests are used to determine package visibility. Any package exports with an x-internal or x-friends modifier will be considered internal. All other packages are considered API. The Patterns tab can be used to augment package visibility information by specifying regular expressions to identify packages, and whether those packages should be considered API or internal. For example, since TPTP specifies all packages as API, the following patterns could be used to identify its internal packages.

An Archive Pattern allows specific jars within bundles to be omitted from the scan. A Package Pattern allows you to specify which packages should be considered API or non-API (override visibility definitions in bundle manifests). A Report Conversion Pattern allows specific references to be filtered from the final report. You can filter references from or to locations based on regular expressions.

For example, to use an archive pattern to filter references from specific archives within bundles, select Archive Pattern and press Next. The wizard allows you to easily craft an archive pattern.

When you press Finish the pattern appears in the Patterns table.

The resulting report could look like the following.

Set the property javacErrors.<library> in your build.properties. Similar to the javacWarnings.<library> property, specify the warnings that should be reported as errors:

    	javacErrors.. = forbidden,discouraged,
    	javacErrors.library.jar = deprecation,nullDereference
    	

• Compiler compliance, source and target levels match jre.compliance.profile, javacSource, and javacTarget properties (only required when compiler settings do not match default settings for a bundle's required execution environment).
• Folders in source.<library> exist, are source folders on the Java build path, and are not duplicated.
• Folders in output.<library> exist, are output folders or class file folders on the Java build path, and are not duplicated.
• Each output.<library> entry contains all output locations of its corresponding source folders on the Java build path.
• Source folders targeted to different libraries do not share the same output location.
• Source folders are not included in src.includes entries (they are included by default).
• Additionally, a check can be performed to ensure an output.<library> exists for each source.<library> entry. By default, this problem is ignored but can be turned on via Preferences > Plug-in Development > Compilers (or project specific Properties > Plug-in Development > Plug-in Manifest Compiler). This option is useful when using the PDE option to export existing class files from the workspace.

When set to Warning or Error problem markers will appear when your project settings are not reflected in build.properties. Quick fixes are available to help you synchronize the settings.

A new javacProjectSettings property is supported in build.properties. The value can be a project relative path to a preference settings file of compiler options supported by the JDT compiler, or it can simply by true to indicate the default preference file should be used (.settings/org.eclipse.jdt.core.prefs).

These arguments will be specified in addition to whatever general compiler arguments are specified by the releng setup.

Set compilerAdapter in the bundle's build.properties file. As well, set sourceFileExtensions to a list of file extensions which should be treated as source and automatically copied to generated source bundles.

org.eclipse.debug.ui_3.6.0.201004141459: the following prerequisites contain compile errors
    org.eclipse.debug.core_3.6.0.201004141459