Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

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 automates the initial installation and configuration of the system, along with bootstrap data for 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 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 and

Coding conventions

  • Where possible, we stick to established Drupal coding conventions.
  • Use two spaces (no tabs) for indenting

Wrapper Classes

  • Creation of wrapper classes for custom content types is encouraged.
    • Class, field, and method names use camel case (e.g. ProjectRole, getProject, etc.)
  • Wrapper class implement a getInstance method that can take a node, or node id as a parameter and answer a corresponding instance. Multiple calls to getInstance for the same node result in the return of the same object. The parameter can take other forms as makes sense for the content type.
  • Static methods that return an existing instance are named get*; e.g. Election::getOngoing(...)
  • Static methods that return multiple existing instances are named getAll*; e.g. Election::getAllOngoing(...)
  • Static __construct method should be marked private if it should not be used


  • All functions names are prefixed with the name of the module.
    • Functions that do not implement Drupal Hooks separate the module name from the function name with two underscore characters (e.g. projects__do_something). Note that we do this to avoid having functions collide with the current or future hook namespace.
  • Use underscores to separate words in function indentifiers.
  • Pick meaningful names for all functions
  • Non API functions should include an @internal entry in the comment


  • Functions that implement Drupal hooks follow the standard convention of separating the module name from the function name with a single underscore character (e.g. projects_node_view)
  • Function comment should include an @see entry that names the hook in the comment.
 * @see hook_block_info()
function project_blocks_block_info() {
  $blocks = array();
  $blocks['projects_navigation'] = array(
    'info' => t('Project Navigation'), 
    'cache' => DRUPAL_NO_CACHE,
    'weight' => 10
  return $blocks;

Back to the top