Jump to: navigation, search

Project Management Infrastructure/Development

The source code for the Project Management Infrastructure will be made open source at some point (likely under the Eclipse Distribution License). If you have questions regarding the availability of the source, please contact EMO.

Issue Tracking

We are tracking issues for the Project Management Infrastructure using the public Eclipse Bugzilla instance. All bugs are recorded under the "Community/Project Management & Portal" component; the subject of records that concern the Project Management Infrastructure is prefixed with '[pmi]'.


The application code is laid out in a directory structure containing several custom modules (details TBD). The system can be manifested directly from these modules. Modules are self-contained, are self-configuring, and self-updatable.

An installation profile for projects.eclipse.org automates the initial installation and configuration of the system, along with bootstrap data for eclipse.org projects.

Application Lifecycle Management

The Project Management Infrastructure is not itself an Eclipse project.

While under development, the system is deployed in two different configurations: one for eclipse.org and one for Polarsys. A major design point is to permit multiple separate deployments with customization ("Foundation in a box").

Source Control

Drupal presents some interesting source control management issues; it is possible to "code" much of a Drupal-based site without ever writing actual code. Many of the development tools provided for Drupal facilitate the construction of elements that exist directly in the database. When those tools are used--such as the Content Construction Toolkit (CCK)--the results are converted into code and included in the code tree. The code tree is committed into Git.

The main Git repository is currently private to employees of the Eclipse Foundation. This will change as development progresses.

Build and Release

Releases are tagged using standard three-part Eclipse version numbering strategy. The first number, the major version is updated for significant milestones (or when significant API breakage occurs); the second number, or minor version is updated with each release that adds or changes functionality; and the third number, or service version is updated for bugfix or service releases.

Builds are generated by tagging and then extracting (via git archive) the state of the system. We need to visit this decision as we do not actually use these builds as part of our deployment.


  • Deploy first to staging servers for testing;
  • When tests pass, deploy to production servers;
  • Deploy directly from git (i.e. git pull);
  • Deployment to both projects.eclipse.org and polarsys.org