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.
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").
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.
- Deployment to both projects.eclipse.org and polarsys.org
- Where possible, we stick to established Drupal coding conventions.
- All functions names are prefixed with the name of the module.
- Use underscores to separate words in function indentifiers.
- 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)
- 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.
- 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.