Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

WTP/Build/Consuming plugins directly from others builds

< WTP‎ | Build
Revision as of 04:30, 22 October 2008 by David williams.acm.org (Talk | contribs) (Advanced topics)

This document is a work in progress ... and the procedure sort of "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"/>

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.

Back to the top