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.
Difference between revisions of "WTP/Build/Consuming plugins directly from others builds"
(→Advanced topics) |
(→Its all in the map file) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | This document is a work in progress ... and the procedure | + | [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= | =Consuming plugins without recompiling= | ||
| Line 25: | Line 25: | ||
unpack="false"/> | unpack="false"/> | ||
</nowiki></pre> | </nowiki></pre> | ||
| + | |||
| + | 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. | 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. | ||
| Line 37: | Line 39: | ||
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. | 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). | ||
| + | |||
[[Category:WTP Build Related| ]] | [[Category:WTP Build Related| ]] | ||
Latest revision as of 22:13, 14 January 2009
[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.]
Contents
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).