Difference between revisions of "WTP/Build/Consuming plugins directly from others builds"
|Line 36:||Line 36:|
Normally, these bundles will already be signed and conditioned for Pack200, so these bundles you'd want to put on your "exclude" list
Normally, these bundles will already be signed and conditioned for Pack200, so these bundles you'd want to put on your "exclude" list time, complications when different VMs are used.
Revision as of 03:30, 22 October 2008
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 email@example.com, 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.
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.)
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.