Jump to: navigation, search

Galileo/Contributing to Galileo Build

< Galileo
Revision as of 13:06, 24 April 2009 by David williams.acm.org (Talk | contribs) (splitting out contributing page)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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"/>
  <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"/>

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, and the Platform team need not include anything that is already declared within the SDK.
  • 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: 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.