Difference between revisions of "Project Management Infrastructure/Development"

From Eclipsepedia

Jump to: navigation, search
(New page: 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 availa...)
 
(Coding conventions)
(2 intermediate revisions by one user not shown)
Line 8: Line 8:
 
* [https://bugs.eclipse.org/bugs/buglist.cgi?list_id=1233948;short_desc=%5Bpmi%5D;classification=Eclipse%20Foundation;query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;short_desc_type=substring;component=Project%20Management%20%26%20Portal;product=CommunityClosed issues]
 
* [https://bugs.eclipse.org/bugs/buglist.cgi?list_id=1233948;short_desc=%5Bpmi%5D;classification=Eclipse%20Foundation;query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;short_desc_type=substring;component=Project%20Management%20%26%20Portal;product=CommunityClosed issues]
 
* [https://bugs.eclipse.org/bugs/buglist.cgi?list_id=1233950;short_desc=%5Bpmi%5D;classification=Eclipse%20Foundation;query_format=advanced;short_desc_type=substring;component=Project%20Management%20%26%20Portal;product=Community All issues]
 
* [https://bugs.eclipse.org/bugs/buglist.cgi?list_id=1233950;short_desc=%5Bpmi%5D;classification=Eclipse%20Foundation;query_format=advanced;short_desc_type=substring;component=Project%20Management%20%26%20Portal;product=Community All issues]
 +
 +
==Structure==
 +
 +
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 <code>git archive</code>) the state of the system.  ''We need to visit this decision as we do not actually use these builds as part of our deployment.''
 +
 +
===Deployment===
 +
 +
* Deploy first to staging servers for testing;
 +
* When tests pass, deploy to production servers;
 +
* Deploy directly from git (i.e. <code>git pull</code>);
 +
* Deployment to both projects.eclipse.org and polarsys.org
 +
 +
==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.
 +
 +
===Functions===
 +
* 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
 +
 +
===Hooks===
 +
* 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.
 +
 +
<pre>/**
 +
* @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;
 +
}</pre>

Revision as of 12:34, 15 May 2012

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.

Contents

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]'.

Structure

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.

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

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.

Functions

  • 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

Hooks

  • 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;
}