Target Platform

From Bioclipse
Jump to: navigation, search


The target platform definition in the file has previously been open-ended: any plugins that happened to live in the plugins directory of your instance of Eclipse were allowed to make it into the Bioclipse build you created. This meant that every developer's Eclipse instance could create Bioclipse binaries with a slightly different collections of plugins than everyone else's. This is probably not what we want.

(Having entirely different plugins arises from the case in which different plugins are chosen to satisfy the same package constraints--possibly even recursively!--and of course having different versions arises from the case where slightly different plugin versions satisfy the same version constraints.)


  1. As a first step, I created a target definition file (i.e., the .target file mentioned above) that lists all the currently-needed plugins. Once you instruct Eclipse to use this target definition, plugins not on this list can no longer contribute to a Bioclipse build. However, this file still allows the plugins that do get used to originate from the plugins/ directory of your local Eclipse installation. (Done.)
  2. As soon as possible, we should create a versioned repository of all the third-party plugins that we need, and then remove the Eclipse plugins directory from the list of allowable locations that plugins can be copied from. This way everyone will be building against the exact same set of plugins.
  3. Following that, we should move to using Automated and Continuous Build Processes. The above steps will help with that process by creating a consistent, versioned base to build on top of.

Missing Plugins Warning: Probably OK to Ignore

When you set the new target platform, you will probably get a dialog telling you about missing plugins. This is to be expected because the target definition file mentions plugin fragments that are specific to the various operating system Bioclipse can be built on, but your OS-specific Eclipse install probably only has the fragments that are relevant for your OS. If Eclipse doesn't flag any new build problems or any configuration problems after you rebuild, you should (probably) be okay.


  • While developing, don't forget to click the "Set As Target" link in the upper right of the 'target editor' that this file opens into within Eclipse!
  • At any time, you can investigate the plugins in the target that PDE is currently using by opening Preferences -> Plug-in Development -> Target Platform (look under the Plug-ins tab)
  • Another way to check what plugins PDE considers to be in the currently-effective target platform is to go to the Plug-ins view, click on the drop-down menu, and make sure that "Show enabled external plug-ins" is checked and that "Show disabled external plug-ins" is UNchecked.
  • A great tool for diagnosing plug-in wiring is the "Plug-in Dependencies" view under PDE. (Available by right-clicking a plug-in in Plug-ins view and selecting "Open Dependencies".) You can see the plugins that require or that are required by any given plugin. (Use the "show callees" and "show callers" buttons on the toolbar.) But the most useful button is the "Show State Status" button; this lets you investigate which the plugins are wired together and whether bundle A requires bundle B via a Require-Bundle header or whether Bundle A is wired to bundle B via an Import-Package header. Once you find a plug-in, you can get back to investigating its dependencies or dependents by selecting it and clicking on the "Focus on selected item" button.
  • Another great tool is the "Plug-in Registry" view under PDE Runtime. For each plugin, this shows the path to the jar supplying the plug-in, its extensions and extension points, embedded libraries, and its prerequisite plugins.

List of Plugins

For now, see for the plugins currently in the target platorm.

But, discuss: What's extraneous? What should be added? Do any of your builds break because of this new target platform?

--Rklancer 04:04, 10 March 2008 (CET)