Difference between revisions of "Europa/Build"

From Eclipsepedia

Jump to: navigation, search
(When The Europa-o-Matic Runs)
 
(17 intermediate revisions by 4 users not shown)
Line 1: Line 1:
This page is related to the [[Europa Simultaneous Release]].
+
{{Europa Deprecation Notice}}
  
These are some brief notes to document how the callisto projects "contribute" to the "Europa Build".  
+
This page is related to the [[Europa Simultaneous Release]].
  
 +
==Explanation==
 
Of course, there really is no "build" of Europa, but only a copying of what is already available on each project's update site, to a central site. Plus, there is a "site.xml" file, and index.html, etc., that are authored, and Europa projects are (relatively) free to make updates to them.  
 
Of course, there really is no "build" of Europa, but only a copying of what is already available on each project's update site, to a central site. Plus, there is a "site.xml" file, and index.html, etc., that are authored, and Europa projects are (relatively) free to make updates to them.  
  
 
The purpose of the build is simply to document the steps in the process, require as little manual intervention as necessary, and have the build be reproducible, version controlled, etc.  
 
The purpose of the build is simply to document the steps in the process, require as little manual intervention as necessary, and have the build be reproducible, version controlled, etc.  
  
 +
 +
 +
==Older Europa-matic==
 +
===Code and Configuration Files===
 
Contributors to the Europa Discovery site need to be aware the CVS Callisto projects.  
 
Contributors to the Europa Discovery site need to be aware the CVS Callisto projects.  
  
Line 20: Line 25:
 
  org.eclipse.europa.updatesite
 
  org.eclipse.europa.updatesite
  
The org.eclipse.europa.tools project has a build-home sub-directory, with several ant files, of the form <code>features-{project}.xml</code>, where {project} is ep, wtp, birt, emf, cdt, dtp, gef, gmf, tptp, ve, etc.
+
===Per Project Configuration And Responsibilities===
 +
(1) The org.eclipse.europa.tools project has a build-home sub-directory, with several ant files, of the form <code>features-{project}.xml</code>, where {project} is ep, wtp, birt, emf, cdt, dtp, gef, gmf, tptp, ve, etc.  
  
Each Europa project's PMC and/or Project Leader is responsible to keep those feature-{project}.xml files up to date as the project releases new milestones and release candidates. The project's project leader will probably delegate to the project's release engineer(s).
+
(2) These features-{project}.xml files are listed in the master <code>updateMirrorAll.xml</code> file.
  
Obviously, each project's own update site must already exist (and be working) at the URL that is specified in the feature-{project}.xml.  
+
(3) The features listed in the features-{project}.xml file are also listed in the master <code>org.eclipse.europa.updatesite/WebContent/site.xml</code> file. There is no need to keep the version numbers in the site.xml correct - the build will update them. The reason for the site.xml is to specify categories for the features. There is also a second file, site-byProject.xml, which requires updating.
  
Typically, as projects move from milestone to milestone (or release candidate to release candidate) only the version identifiers in their feature-{project}.xml file have to be changed. There might, for some projects, be times when the feature ids themselves have to change or perhaps the URL will change as to where to find the project's update site.  
+
Each Europa project's PMC and/or Project Leader is responsible to keep those features-{project}.xml files and the site*.xml files up to date as the project releases new milestones and release candidates. The project's project leader will probably delegate to the project's release engineer(s).
  
On a regular schedule, or on request by a project that has just updated their feature-{project}.xml file, Bjorn does the following:  
+
Obviously, each project's own update site must already exist (and be working) at the URL that is specified in the features-{project}.xml.
 +
 
 +
Typically, as projects move from milestone to milestone (or release candidate to release candidate) only the version identifiers in their feature-{project}.xml file have to be changed. There might, for some projects, be times when the feature ids themselves have to change or perhaps the URL will change as to where to find the project's update site.
 +
 
 +
After a project's release engineer updates their features-{project}.xml file, they should notify the rest of the Europa team via an email to the eclipse.org-cross-project-issues-dev@ mailing list.
 +
 
 +
===What The Europa-o-Matic Does===
 +
On a regular schedule (see below), or on specific request from any project, Bjorn does the following:  
  
 
# An ant task uses the update manager's mirror function to pull features from the projects' updates sites, copying them to the Europa staging site.  
 
# An ant task uses the update manager's mirror function to pull features from the projects' updates sites, copying them to the Europa staging site.  
 
# The log results of this mirroring are published [http://dash.eclipse.org/~bfreeman/europa/ here]. (Eventually there may be an automated email notification as well.) Projects are responsible for making their portion go green.
 
# The log results of this mirroring are published [http://dash.eclipse.org/~bfreeman/europa/ here]. (Eventually there may be an automated email notification as well.) Projects are responsible for making their portion go green.
# Once the build goes green, the Europa site.xml file is updated with the new feature versions and copied to the staging site <code>http://download.eclipse.org/releases/europa/staging</code>
+
# Once the build goes green, the Europa site.xml file is updated with the new feature versions and copied to the staging site <code>http://download.eclipse.org/releases/europa/staging</code> (the site does not work, please update)
# After the the staging site has been tested by the projects, to indeed discover and install the right versions, on the right platforms, etc., there will be a "mass delete and mass copy" of the staging site to the release site. The release site is <code>http://download.eclipse.org/releases/europa/releases</code>
+
# After the the staging site has been tested by the projects, to indeed discover and install the right versions, on the right platforms, etc., there will be a "mass delete and mass copy" of the staging site to the release site. The release site is <code>http://download.eclipse.org/releases/europa/site.xml</code>
 
#* This release is coordinated with the webmaster, so that the mirrors have time to replicate /europa/relases (note that staging is not mirrored, since it is for testing only, and may be created and re-created frequently, which would cause unnecessary noise on the mirror network).
 
#* This release is coordinated with the webmaster, so that the mirrors have time to replicate /europa/relases (note that staging is not mirrored, since it is for testing only, and may be created and re-created frequently, which would cause unnecessary noise on the mirror network).
 +
 +
===When The Europa-o-Matic Runs===
 +
 +
As of 2007/10/01, the Europa builds are run manually by request; scheduled builds will resume as we near the Winter Maintenance dates. The build takes about two hours and the results are placed in the Europa staging update site. The log is http://dash.eclipse.org/~bfreeman/europa/.
 +
 +
[[Category:Europa]] [[Category:Coordinated]] [[Category:Releng]]

Latest revision as of 18:48, 1 October 2007

Note: This page discusses topics related to the 2007 Europa Simultaneous Release. Most of the Europa pages are deprecated. You are urged to find current information on pages related to the 2008 effort, currently named the Ganymede Simultaneous Release.

This page is related to the Europa Simultaneous Release.

Contents

[edit] Explanation

Of course, there really is no "build" of Europa, but only a copying of what is already available on each project's update site, to a central site. Plus, there is a "site.xml" file, and index.html, etc., that are authored, and Europa projects are (relatively) free to make updates to them.

The purpose of the build is simply to document the steps in the process, require as little manual intervention as necessary, and have the build be reproducible, version controlled, etc.


[edit] Older Europa-matic

[edit] Code and Configuration Files

Contributors to the Europa Discovery site need to be aware the CVS Callisto projects.

:extssh:<your-committer-id-goes-here>@dev.eclipse.org:/cvsroot/callisto

Or, general "read" access via

:pserver:anonymous@dev.eclipse.org:/cvsroot/callisto

There are two projects there:

org.eclipse.europa.tools
org.eclipse.europa.updatesite

[edit] Per Project Configuration And Responsibilities

(1) The org.eclipse.europa.tools project has a build-home sub-directory, with several ant files, of the form features-{project}.xml, where {project} is ep, wtp, birt, emf, cdt, dtp, gef, gmf, tptp, ve, etc.

(2) These features-{project}.xml files are listed in the master updateMirrorAll.xml file.

(3) The features listed in the features-{project}.xml file are also listed in the master org.eclipse.europa.updatesite/WebContent/site.xml file. There is no need to keep the version numbers in the site.xml correct - the build will update them. The reason for the site.xml is to specify categories for the features. There is also a second file, site-byProject.xml, which requires updating.

Each Europa project's PMC and/or Project Leader is responsible to keep those features-{project}.xml files and the site*.xml files up to date as the project releases new milestones and release candidates. The project's project leader will probably delegate to the project's release engineer(s).

Obviously, each project's own update site must already exist (and be working) at the URL that is specified in the features-{project}.xml.

Typically, as projects move from milestone to milestone (or release candidate to release candidate) only the version identifiers in their feature-{project}.xml file have to be changed. There might, for some projects, be times when the feature ids themselves have to change or perhaps the URL will change as to where to find the project's update site.

After a project's release engineer updates their features-{project}.xml file, they should notify the rest of the Europa team via an email to the eclipse.org-cross-project-issues-dev@ mailing list.

[edit] What The Europa-o-Matic Does

On a regular schedule (see below), or on specific request from any project, Bjorn does the following:

  1. An ant task uses the update manager's mirror function to pull features from the projects' updates sites, copying them to the Europa staging site.
  2. The log results of this mirroring are published here. (Eventually there may be an automated email notification as well.) Projects are responsible for making their portion go green.
  3. Once the build goes green, the Europa site.xml file is updated with the new feature versions and copied to the staging site http://download.eclipse.org/releases/europa/staging (the site does not work, please update)
  4. After the the staging site has been tested by the projects, to indeed discover and install the right versions, on the right platforms, etc., there will be a "mass delete and mass copy" of the staging site to the release site. The release site is http://download.eclipse.org/releases/europa/site.xml
    • This release is coordinated with the webmaster, so that the mirrors have time to replicate /europa/relases (note that staging is not mirrored, since it is for testing only, and may be created and re-created frequently, which would cause unnecessary noise on the mirror network).

[edit] When The Europa-o-Matic Runs

As of 2007/10/01, the Europa builds are run manually by request; scheduled builds will resume as we near the Winter Maintenance dates. The build takes about two hours and the results are placed in the Europa staging update site. The log is http://dash.eclipse.org/~bfreeman/europa/.