Galileo/Build (deprecated)

This page as a whole is now deprecated, since we are moving to the Buckminster based builder.

The method and process of making a contribution to the build is exactly the same, so I've split the contribution instructions out into their own document.

Overview

Galileo is built using PDE build and p2. A galileo.product file is augmented with a build model to define all of the necessary parameters needed for build script generation. The build model is composed of individual contribution models (.build files), similar to the Ganymede build's use of .sc files. The build is produced through the following steps, which are (to be) invoked using Hudson:

• Ant is used to download a DSL Toolkit configuration, as it contains the necessary modeling plug-ins and builder project provided by Amalgam
• Ant then invokes QVT model-to-model and Xpand model-to-text transformations on the galileo.product and galileo.build models to produce the build scripts and artifacts
• The generated build.xml is invoked, which starts a PDE product build followed by p2.director calls to assemble the Galileo product
• The p2 artifact and content repositories produced by the build (http://build.eclipse.org/galileo/build/galileo/repo/) process are published per milestone to http://download.eclipse.org/releases/galileo

Contributing to Galileo

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, 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.

Building Locally

If you've downloaded the DSL Toolkit, it's quite easy to run a local build of Galileo using the following steps:

• Check out the org.eclipse.galileo.build project into your workspace (you may need to activate the Team capability)
• Open galileo.build and adjust the Platform element to match your environment. The Galileo build runs on build.eclipse.org, which is a PPC machine running Linux and likely not your local environment. You'll likely only need the ending of the File property, e.g. eclipse-SDK-3.5M3-linux-gtk-ppc.tar.gz to eclipse-SDK-3.5M3-macosx-carbon.tar.gz
• Select a Config element that matches your environment, which you may need to create first. Delete the other Config elements, unless you want to produce a number of platform-specific Galileo products locally (doubtful).
• In the Build Galileo root element, adjust the Launch VM property to match your environment. If your default VM is Java 5, you can simply delete the value that is there by default. The build.eclipse.org machine uses a 1.4.2 VM by default, unfortunately.
• Also in the Build Galileo root element, enter a local path to run the build in. If you enter a fully-qualified path to the current workspace plus "/out/build" you will be able to immediately invoke the scripts following generation to their default output directory.
• Select generate.xml in the project and create a new External Tools Configuration to invoke an Ant Build. Be sure to select "Run in the same JRE as the workspace" on the JRE tab. Run the generation script and observe the generated build files in the /out directory.
• In the out/build/galileo directory, invoke the build.xml Ant script to run the build.

If you're interested in adjusting the output of the build script generation itself, switch to the Plug-in Development perspective and import the org.eclipse.amalgam.releng.builder project into your workspace. Modify the Xpand templates and/or QVT script as desired and regenerate after adjusting the generate.xml script in the org.eclipse.galileo.build project to reference platform:/resource and not platform:/plugin URIs, where applicable.