Galileo/Contributing to Galileo Build

Contributing to Galileo Build

The following steps are required when contribute to Galileo:

• Checkout the project org.eclipse.galileo.build from /cvsroot/callisto. If you do not have write access to this repository location, contact the webmaster.
• Modify the content of your project/component build model to indicate the features, versions, contact info, and category information for your contribution. Below is an example of a build model:

<?xml version="1.0" encoding="ASCII"?>
<build:Contribution xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:build="http://www.eclipse.org/amalgam/2008/build" label="GMF">
  <contacts name="Richard Gronback" email="richard.gronback@borland.com"/>
  <features id="org.eclipse.gmf.sdk" version="2.2.0.v20080917-1925-7A7A3AImms9uVK-KldWYTMMy9wOh" repo="//@repositories.1">
    <category href="galileo.build#//@categories.0"/>
  </features>
  <repositories location="http://download.eclipse.org/modeling/gmf/updates/milestones/" label="GMF milestones"/>
  <repositories location="http://download.eclipse.org/modeling/gmf/updates/interim/" label="GMF interim"/>
</build:Contribution>

If you're not comfortable modifying EMF-based model instances in a text editor, download the latest DSL Toolkit, as it provides an EMF generated editor for build models. The editor allows each contribution to be maintained in its own file, so when creating a new Contribution within the galileo.build model, use the right-click Control... menu to specify a new .build model. Model files can be opened individually, or you can open the main galileo.build model to edit your contribution.

Repository elements are maintained within each contribution .build model, as are the list of contacts used to inform contributors of build breakage. A number of repositories may be listed in each contribution, as each feature/version references a specific repository location for installation during the build. Having multiple entries allows for easy switching between repositories.

A feature element has some properties that may require clarification:

• Category: used to indicate the category the feature will appear in when displayed in the p2 UI and update site manifest. Note that categories are specified in the main galileo.build model and are not intended to be modified without agreement of the Planning Council. Mapping categories is best done within the build model editor provided by the DSL Toolkit, though can be done within a text editor if you're careful.
• InProduct: a flag to indicate whether or not the feature should be listed in the product file. Nested features need not be included explicitly.
• Repo: the Repository element reference that is used to install the feature from. Note that the Platform team need not set this element as the entire SDK is used as the basis for each build.

Note: Occasionally the your .build file may be changed by the buildmaster, so be sure to use the latest version when making your modifications and submissions. Changes might include insubstantial things like formatting and end-of-line characters (best to leave the same, but no absolute need) but will sometimes contain substantial changes such as the "category number" may change (which is substantial, and must be maintained).

Note: Order matters. If you contribute several features that should be installed into the build target in a particular order, please list them as such in the build model.

Note: Include all platform-specific bundles. Just as the platform provides a delta pack that contains those bundles required for each supported platform, each contributing project to Galileo must include a feature that contains each platform-specific bundle, or specify each bundle using the proper entry in their build model. For an example, see the cdt.build model.

Note: For the email addresses, use an actual email address that goes to a person. You can give several, so messages are sent to several people. Do not use a "dev mailing list" at Eclipse, since those require a subscription and the builder that automatically sends emails about broken builds, etc. does not subscribe to the dev mailing lists at Eclipse.