WTP/Build/Consuming plugins directly from others builds

[This document is currently a work in progress ... and the procedure "experimental" until someone actually uses it on a regular basis. If you have questions or comments, feel free to ask on wtp-releng@eclipse.org, or open a bug on the WTP Releng project.]

Consuming plugins without recompiling

Usually people want all of WTP or substantial sections of it, so they download a zip file of features and plugins to use in their builds and/or distributions.

There is another need, occasionally, when someone may want just one or two (or a few) plugins and maybe don't even care about the features per se. One option, some people have used, is to just re-build the source into your own bundle. This can work, but quite a bit of care needs to be made to make sure it is built exactly the same way ... same VM, same compiler, same settings, etc., or else you run the risk of having two plugins with exact same version (down to the qualifier) but which have slightly different bits inside. Not a good thing.

And easier way, is to get the bundles that WTP has already build. There are ways to "get" these pre-built bundles using the same PDE build techniques developed in the context of Orbit. Many of these concepts are documented much more fully in the Orbit project, but here we'll document the procedure here in the context of WTP.

Its all in the map file

In the example below, we'll just imagine someone wanted to use only the org.eclipse.wst.common.project.facet.core plugin in their builds and distributions.

The first step to to define your own features, however you'd like, however you normally do, and in one of them, which ever is conceptually appropriate, add the normal elements to include that plugin. Something similar to

   <plugin
      id="org.eclipse.wst.common.project.facet.core"
      download-size="0"
      install-size="0"
      version="0.0.0"
      unpack="false"/>

Note: for PDE build to actually include this non-compiled plugin in the zip file of your feature, you should specify the build property runPackager=true (see Eclipse Help for more information about build properties).

And, then, in the map file, instead of including a line that is cvs oriented, you can include a line that is HTTP oriented. This is the clue that PDE Batch build uses to know just to download the bundle, and not try to download source or re-compile anything. The map file, for a WTP bundle, would look something similar to the following very long line.

 plugin@org.eclipse.wst.common.project.facet.core,1.3.100=GET,http://download.eclipse.org/webtools/downloads/drops/R3.1/S-3.1M2-20080928142920/updateSite/plugins/org.eclipse.wst.common.project.facet.core_1.3.100.v200809022150.jar

Orbit produces these sort of map files every build, for the convenience of consumers. Perhaps WTP should as well, if there is enough demand. (See bug 251663.)

Advanced topics

Normally, these bundles will already be signed and conditioned for Pack200, so for these bundles you'd want to put them on your "exclude" list when you do conditioning and signing. This not only saves time, but also avoids certain complications when different VMs are used.

Related Policies

Note that normally, these type of jointly consumed bundles may have to effectively be on a different, earlier schedule than the rest of the project, so they can be done and ready for consumption by all projects making use of it (for example, WTP and DTP are both +2 projects).