Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Galileo/Contributing to Galileo Build"

(splitting out contributing page)
 
(clarified to "use the latest" version.)
 
(2 intermediate revisions by one other user not shown)
Line 22: Line 22:
  
 
A feature element has some properties that may require clarification:
 
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.
+
* 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.
+
* 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.
 
* 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''': 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''': 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.
 +
 +
  
  
 
[[Category:Galileo]]
 
[[Category:Galileo]]

Latest revision as of 10:42, 12 May 2009

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.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.