Difference between revisions of "PDE/FAQ"

Revision as of 12:49, 6 May 2010

General

What is PDE

The Plug-in Development Environment (PDE) provides tools to create, develop, test, debug, build and deploy OSGi bundles and RCP applications.

Installation

How do I install PDE?

TODO

Target Management

Why do I get an popup dialog saying I have selected a target with a newer version than your current Eclipse installation?

This happens because PDE detects a newer version of the OSGi runtime in your target platform than in your host installation. To resolve this problem, don't point to a target that may contain future versions of Eclipse or just upgrade your current host to a newer version of Eclipse. In the end, this message is trying to convey that PDE is backwards compatible only, not forward compatible.

Also, see our Target Definitions page.

Products

Why doesn't my JRE get included in a headless build?

At the moment, there is a disparity between PDE UI and Build when it comes to JREs and product definitions. The best way to get your JRE to be included in a headless and UI build is to use root files.

Classpath

How do I find a plug-in (bundle) given a class

If you're interested in finding a class at runtime, please use the PackageAdmin service from OSGi

How do I get access to a plug-in (bundle) in my workspace or target

Use the PluginRegistry API to acquire models from your workspace or target

I have an error that says some package (e.g., com.sun.misc) isn't accessible but it's on my classpath

In most cases, people get this error by accessing the Base64 class from the Sun VM. We generally don't recommend using the Base64 class from the VM because your bundle will be tired to only VMs that have that specific class. However, if this isn't an issue, you can get around the access restriction error by adding an access rule to your system library to make the package accessible. You can do this on the Libraries tab of the Java Build Path project properties. Add an Accessible rule for com/sun/misc/*

Also, in most cases, this package needs to be visible during runtime. To have a package visible during runtime, you will need to add the org.osgi.framework.system.packages.extra system property. For example:

org.osgi.framework.system.packages.extra==com.sun.misc,com.sun.java.swing.plaf.windows 

API Tooling

How do I enable API Tooling for my projects

Enabling API Tooling on a project is described here.

Build

How do I build from SVN

Out of the box, PDE Build does not have the ability to fetch code from a subversion repository. Some discussion have started to make Subversive Fetch tasl part of the BaseBuilder. Subversive provides an SVN fetch task. The corresponding plugin can be downloaded from Subversive's website and some documentation can be found on dedicated wiki page.

Before that, Chris Vines from the community created a plug-in adding this support. It can be found at [1]. Any specific problem with this plug-in must be reported there too.

How do I add 'Eclipse-SourceReferences' Headers

Out of the box, PDE build does not generate Eclipse-SourceReferences headers when building bundles. The following property must be specified:

generateSourceReferences = true

For more infomration see Source Reference Headers

Misc

How do I add my own template to the New Plug-in Project Wizard

The org.eclipse.pde.ui.pluginContent extension point is what you need. There's a fantastic article on this topic at developerWorks.

How do I know if my project is a plug-in project

In PDE, projects have a specific nature (see the .project file) associated with them if they are a plug-in. The PDE nature is:

org.eclipse.pde.PluginNature

A typical .project in a plug-in project will look like this:

<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
	<name>org.eclipse.ui.views.log</name>
	<comment></comment>
	<projects>
	</projects>
	<buildSpec>
		<buildCommand>
			<name>org.eclipse.jdt.core.javabuilder</name>
			<arguments>
			</arguments>
		</buildCommand>
		<buildCommand>
			<name>org.eclipse.pde.ManifestBuilder</name>
			<arguments>
			</arguments>
		</buildCommand>
		<buildCommand>
			<name>org.eclipse.pde.SchemaBuilder</name>
			<arguments>
			</arguments>
		</buildCommand>
		<buildCommand>
			<name>org.eclipse.pde.api.tools.apiAnalysisBuilder</name>
			<arguments>
			</arguments>
		</buildCommand>
	</buildSpec>
	<natures>
		<nature>org.eclipse.pde.PluginNature</nature>
		<nature>org.eclipse.jdt.core.javanature</nature>
		<nature>org.eclipse.pde.api.tools.apiAnalysisNature</nature>
	</natures>
</projectDescription>

How do source attachments for bundles work

Since Eclipse 3.4 Eclipse Bundle JARs are accompanied by separate source bundles (see Bug 202462 simplify the way source is contributed):

javax.servlet_2.5.0.v200910301333
javax.servlet.source_2.5.0.v200910301333

The source bundle has to contain the Eclipse-SourceBundle header in its MANIFEST.MF, attaching the sources to the actual bundle:

Bundle-SymbolicName: javax.servlet.source
Eclipse-SourceBundle: javax.servlet;version="2.5.0.v200910301333"

When you build bundles using PDE build, you can choose to generate these source bundles.

Please note that it is not possible to attach sources manually for bundles because the classpath is created from the MANIFEST.MF content automatically. Manual changes to the classpath container are not allowed because they would be overwritten.