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.
Difference between revisions of "Platform-releng/Indigo Build Changes"
(New page: = Overview = This document captures work to be performed on the Eclipse project build process during the Indigo development cycle (July 2010 to June 2011). There are three main a...) |
(→Move to GIT) |
||
| (7 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
= Overview = | = Overview = | ||
| − | This document captures work to be performed on the [[Eclipse]] project build process during the [[Indigo]] development cycle (July 2010 to June 2011). There are three main areas of work | + | This document captures work to be performed on the [[Eclipse]] project build process during the [[Indigo]] development cycle (July 2010 to June 2011). There are three main areas of work. In addition, a fourth area of investigation (Git migration) may start during this development period depending on available resources. |
# Consolidate 3.x and 4.x stream builds | # Consolidate 3.x and 4.x stream builds | ||
# Migrate build to eclipse.org hardware | # Migrate build to eclipse.org hardware | ||
# Migrate to using Hudson | # Migrate to using Hudson | ||
| + | # Migration to Git. | ||
| − | * change e4 bundle ownership to new groups | + | = Consolidating 3.x and 4.x stream builds = |
| + | |||
| + | Currently the 4.x stream build repeats much of the same work as the 3.x stream build. Also, many of the bundles in 4.x are still produced by the [[e4]] build process even though the components have graduated/moved into the [[Platform]] project. Instead, the 4.x build should consume nothing from e4, and only build the bundles that are actually new or changed in the 4.x stream. | ||
| + | |||
| + | The following steps are needed to get to this point: | ||
| + | |||
| + | * change e4 bundle ownership to new groups as described by the e4->platform move review | ||
* Move forked org.eclipse.ui.workbench bundle into a branch of the real project | * Move forked org.eclipse.ui.workbench bundle into a branch of the real project | ||
| − | * Refactor e4 features to keep dependencies clean | + | * Refactor e4 features to keep dependencies clean |
| + | ** Separate graduated parts of CSS and modeled UI into separate features | ||
| + | ** Have org.eclipse.rcp include the relevant CSS and modeled UI features | ||
* Change order of build to (3.7->4.1->e4 instead of (3.7->e4->4.1) | * Change order of build to (3.7->4.1->e4 instead of (3.7->e4->4.1) | ||
| + | ** Fetch graduated e4 bundles as source rather than binary in 4.1 build | ||
| + | ** Fetch graduated e4 bundles as binary from the 4.1 repository in the e4 build | ||
* Signing of 4.1 builds | * Signing of 4.1 builds | ||
** Short form of 4.1 build currently doesn't sign | ** Short form of 4.1 build currently doesn't sign | ||
| − | ** Find a custom target somewhere in the 4.x build to perform signing of the right contents. After compile (post build) | + | ** Find a custom target somewhere in the 4.x build to perform signing of the right contents. After compile (post build). |
| − | + | ** Andrew to investigate and come up with a recommendation | |
| − | + | ||
| − | + | ||
| − | ** | + | |
* e4 bundle/package rename... | * e4 bundle/package rename... | ||
| − | * | + | ** Currently e4 bundles that graduated to platform still have "org.eclipse.e4..." in the name. They should be renamed to org.eclipse.platform... or something similar. |
| + | ** In some cases simply dropping "e4" from the bundle/package names would create ambiguity/collision with legacy 3.x bundle/package names. Likely want some way to keep the "old" and "new" bundles separate | ||
| + | ** Once new names are decided, move graduated bundle into new home under /cvsroot/eclipse with their new name. | ||
* Running all Eclipse SDK tests | * Running all Eclipse SDK tests | ||
| − | ** fork tests that are affected by 4.x changes | + | ** Currently 4.1 build does not run any tests |
| + | ** Need to fork tests that are affected by 4.x changes | ||
| + | ** Strictly speaking only need to run platform tests, but running JDT/PDE tests could also be helpful in picking up platform regressions in 4.x stream (or incorrect assumptions in JDT/PDE about platform behaviour or API) | ||
* Fork platform doc (ISV and user) | * Fork platform doc (ISV and user) | ||
| + | ** Once 4.1 stream has distinct documentation, will need to fork the two documentation bundles | ||
| + | ** Update screen shots, etc, in 4.1 doc | ||
| + | ** Add new 4.1 API to the javadoc in the 4.1 doc | ||
| + | |||
| + | = Moving to Hudson = | ||
| + | |||
| + | * Currently have a permission problem, hudson build cannot promote builds to download directory. Most projects using hudson keep "build" and "promotion" as separate steps | ||
| + | * need separate cron job to promote build afterwards (potentially chained to build so that it promotes automatically | ||
| + | * Currently platform build not factored to handle this (i.e., make promotion a distinct step) | ||
| + | = Moving to eclipse.org hardware = | ||
| + | * Setting up windows tests - need to figure out how to spawn windows tests (virtualize or not?) | ||
| + | * Mac OS missing - IBM donation unlikely but perhaps another company will step forward | ||
| + | * performance tests hard on eclipse.org because virtualized test machine is not stable enough. Will likely need to continue running performance tests on IBM hardware. This is not too bad because it is only on three builds per week and not running with every build. | ||
| − | + | = Move to GIT = | |
| − | + | * Blocked by lack of a Git fetch factory for PDE | |
| − | + | * Need to bundle eGit and feature factory in base builder | |
| − | + | * Potential problem bundling eGit in base builder if eGit is not graduated | |
| + | * Can we just move some bundles to GIT or does the entire project have to move? | ||
| + | ** Candidate deeplink feature in e4 project as a guinea pig | ||
| − | + | [[Category:Eclipse_Platform_Releng| ]] | |
| − | + | ||
| − | + | ||
| − | + | ||
Revision as of 16:51, 15 March 2012
Contents
Overview
This document captures work to be performed on the Eclipse project build process during the Indigo development cycle (July 2010 to June 2011). There are three main areas of work. In addition, a fourth area of investigation (Git migration) may start during this development period depending on available resources.
- Consolidate 3.x and 4.x stream builds
- Migrate build to eclipse.org hardware
- Migrate to using Hudson
- Migration to Git.
Consolidating 3.x and 4.x stream builds
Currently the 4.x stream build repeats much of the same work as the 3.x stream build. Also, many of the bundles in 4.x are still produced by the e4 build process even though the components have graduated/moved into the Platform project. Instead, the 4.x build should consume nothing from e4, and only build the bundles that are actually new or changed in the 4.x stream.
The following steps are needed to get to this point:
- change e4 bundle ownership to new groups as described by the e4->platform move review
- Move forked org.eclipse.ui.workbench bundle into a branch of the real project
- Refactor e4 features to keep dependencies clean
- Separate graduated parts of CSS and modeled UI into separate features
- Have org.eclipse.rcp include the relevant CSS and modeled UI features
- Change order of build to (3.7->4.1->e4 instead of (3.7->e4->4.1)
- Fetch graduated e4 bundles as source rather than binary in 4.1 build
- Fetch graduated e4 bundles as binary from the 4.1 repository in the e4 build
- Signing of 4.1 builds
- Short form of 4.1 build currently doesn't sign
- Find a custom target somewhere in the 4.x build to perform signing of the right contents. After compile (post build).
- Andrew to investigate and come up with a recommendation
- e4 bundle/package rename...
- Currently e4 bundles that graduated to platform still have "org.eclipse.e4..." in the name. They should be renamed to org.eclipse.platform... or something similar.
- In some cases simply dropping "e4" from the bundle/package names would create ambiguity/collision with legacy 3.x bundle/package names. Likely want some way to keep the "old" and "new" bundles separate
- Once new names are decided, move graduated bundle into new home under /cvsroot/eclipse with their new name.
- Running all Eclipse SDK tests
- Currently 4.1 build does not run any tests
- Need to fork tests that are affected by 4.x changes
- Strictly speaking only need to run platform tests, but running JDT/PDE tests could also be helpful in picking up platform regressions in 4.x stream (or incorrect assumptions in JDT/PDE about platform behaviour or API)
- Fork platform doc (ISV and user)
- Once 4.1 stream has distinct documentation, will need to fork the two documentation bundles
- Update screen shots, etc, in 4.1 doc
- Add new 4.1 API to the javadoc in the 4.1 doc
Moving to Hudson
- Currently have a permission problem, hudson build cannot promote builds to download directory. Most projects using hudson keep "build" and "promotion" as separate steps
- need separate cron job to promote build afterwards (potentially chained to build so that it promotes automatically
- Currently platform build not factored to handle this (i.e., make promotion a distinct step)
Moving to eclipse.org hardware
- Setting up windows tests - need to figure out how to spawn windows tests (virtualize or not?)
- Mac OS missing - IBM donation unlikely but perhaps another company will step forward
- performance tests hard on eclipse.org because virtualized test machine is not stable enough. Will likely need to continue running performance tests on IBM hardware. This is not too bad because it is only on three builds per week and not running with every build.
Move to GIT
- Blocked by lack of a Git fetch factory for PDE
- Need to bundle eGit and feature factory in base builder
- Potential problem bundling eGit in base builder if eGit is not graduated
- Can we just move some bundles to GIT or does the entire project have to move?
- Candidate deeplink feature in e4 project as a guinea pig