Common Build Infrastructure/Getting Started/FAQ/Plugin Health And Best Practices

Draft Content
This page is currently under construction. Community members are encouraged to maintain the page, and make sure the information is accurate.

Below are some tips for keeping your plugins & features healthy so that your builds stay green:

• Run the Organize Manifest Wizard for your plugins. This will catch the most common errors of packages not being exported that should be.

• clean up all the warnings/errors that PDE provides

• make sure all plugins have x.y.z.qualifier as their version instead of x.y.z

• when defining a requirement on a bundle (or package) I prefer Require-Bundle, since it's easier for me to deduce from which file to resolve the dependency when building. You may prefer Import-Package - YMMV.

• if you must define a dependency VERSION, set a range like bundle-version="[2.0.0,3.0.0)" instead of bundle-version="2.0.0", so that the qualifier can be added and not break the build.

• make sure that all new plugins are included in the runtime (or SDK) feature, ideally WITHOUT a version number (so that the version can be generated)

• make sure that features declare the plugins on which they depend (PDE can generate this list for you)

• make sure that ALL the files you need to ship are included in the build.properties file; build.properties itself should be included in the src.includes; you can use wildcards (build.* or plugin.*) if you'd like

• make sure that the bin/ folder in your plugin is EXCLUDED from CVS or SVN; this folder should NOT be checked in, ever

• make sure that your plugin's manifest declares "Bundle-ClassPath: ." or nothing; you should ideally not build nested jars if you can avoid it. This improves performance when installing and running the plugin. As such your build.properties should have "source.." instead of "source.somejar.jar"

• if you want to generate a source plugin or feature, make sure you add a directive to the build.properties of the containing feature (usually the SDK feature or test), eg:

generate.plugin@org.foo.ui.test.source=org.foo.ui.test

or

generate.feature@org.foo.source.feature=org.foo.feature

When adding a new plugin:

• make sure that you add the new plugin to the releng/maps/*.map

• make sure that you add the new plugin to the releng/psfs/*.psf

• make sure that you add the new plugin to the feature manifest (feature.xml) that contains it (usually the runtime feature).

• if your project has per-plugin source plugins, add another directive in the containing feature's build.properties to generate that new source plugin