Project Plan For Orion, version 1.0

Introduction

Last revised 11:00 ET November 9th, 2012.

Please send comments about this plan to the orion-dev@eclipse.org developer mailing list.

This document lays out the feature and API set for the next feature release of the Orion project after 0.5, designated release 1.0.

Plans do not materialize out of nowhere, nor are they entirely static. To ensure the planning process is transparent and open to the entire Eclipse community, we (the Orion project leadership) post plans in an embryonic form and revise them throughout the release cycle.

The first part of the plan deals with the important matters of release deliverables, release milestones, target operating environments, and release-to-release compatibility. These are all things that need to be clear for any release, even if no features were to change.

The remainder of the plan consists of plan items for components of the Orion project. Each plan item covers a feature or API that is to be added to the Orion project deliverables, or some aspect of the Orion project that is to be improved. Each plan item has its own entry in the Eclipse bugzilla database, with a title and a concise summary (usually a single paragraph) that explains the work item at a suitably high enough level so that everyone can readily understand what the work item is without having to understand the nitty-gritty detail.

Not all plan items represent the same amount of work; some may be quite large, others, quite small. Some plan items may involve work that is localized to a single component; others may involve coordinated changes to several components; other may pervade the entire project. Although some plan items are for work that is more pressing than others, the plan items appear in no particular order.

With the previous release as the starting point, this is the plan for how we will enhance and improve it. Fixing bugs, improving test coverage, documentation, examples, performance tuning, usability, etc. are considered routine ongoing maintenance activities and are not included in this plan unless they would also involve a significant change to the API or feature set, or involve a significant amount of work. The intent of the plan is to account for all interesting feature work.

The current status of each plan item is noted:

  • Committed plan item - A committed plan item is one that we have decided to address for the release.
  • Proposed plan item - A proposed plan item is one that we are considering addressing for the release. Although we are actively investigating it, we are not yet in a position to commit to it, or to say that we won't be able to address it. After due consideration, a proposal will either be committed or deferred.
  • Deferred plan item - A reasonable proposal that will not make it in to this release for some reason is marked as deferred with a brief note as to why it was deferred. Deferred plan items may resurface as committed plan items at a later point.

Release Deliverables

The release deliverables have the same form as previous releases, namely:

  • Source code release for all Orion project deliverables, available as versions tagged "R1_0" in the Orion project Git repositories.
  • Packaged Orion server download for Windows, Mac, and Linux
  • Hosted Orion server on http://orionhub.org

Table of Contents

Release Milestones

Release milestones will be occurring at roughly 6 week intervals, followed by a short end-game consisting of three release candidates.

M108/10/2012
1.0M1
M209/21/2012
1.0M2
RC110/05/2012
1.0RC1
RC210/12/2012
1.0RC2
RC310/19/2012
1.0RC3

A more detailed, milestone-level plan for the Orion project can be found on the Orion Milestone Plan wiki page.

Our target is to complete 1.0 in October 2012, in concert with the EclipseCon Europe. All release deliverables will be available for download as soon as the release has been tested and validated in the target operating configurations listed below.

Table of Contents

Target Environments

In order to remain current, each Orion project release targets reasonably current operating environments. We focus our testing on a handful of popular combinations of operating systems, Web browsers, and Java platforms; these are our reference platforms. Orion undoubtedly runs fine in many operating environments beyond the reference platforms we test. However, since we do not systematically test them we cannot vouch for them. Problems encountered when running Orion on a non-reference platform that cannot be recreated on any reference platform will be given lower priority than problems with running Orion on a reference platform.

Orion has two broad classes of target environments:

  1. Client target environments Indicates environments supported for end users of Orion-based web applications.
  2. Server target environments Indicates requirements for the platform where the Orion server is installed.

Most of the Orion client code is built on HTML5, CSS3, and ECMAScript 5 (JavaScript). As such, the chief dependence is on a web browser that supplies rendering and interpretation of these languages. In general, Orion requires the most recent major release of the major browsers it supports. Due to the fast pace of development in the browser world, supporting older browser versions is not a priority for Orion at this early stage of its development.

Orion 1.0 is tested and validated on the following reference client target environments:

Operating System Version Browsers
Windows 7 Chrome
Firefox
Internet Explorer 9.0
Red Hat Enterprise Linux 6 Chrome
Firefox
Apple Mac OS X 10.7.4 Safari 5.1.7

Most of the Orion server code is "pure" Java code and has no direct dependence on the underlying operating system. The chief dependence is therefore on the Java Platform itself. Portions are targeted to specific classes of operating environments, requiring their source code to only reference facilities available in particular class libraries (e.g. Java SE 5, Java SE 6, etc). In general, the 1.0 release of the Orion server is developed and tested on Java SE 6.

The Orion 1.0 server is tested and validated on the following reference server target environments:

Operating System Version Hardware JRE
Windows 7 x86 32-bit Oracle Java 6 Update 29
IBM Java 6 SR9 FP2
x86 64-bit
Red Hat Enterprise Linux 6 x86 32-bit Oracle Java 6 Update 29
IBM Java 6 SR9 FP2
x86 64-bit
Apple Mac OS X 10.7 Universal 64-bit Java for Mac OS X 10.7 Update 1

As stated above, we expect that Orion works fine on other current Java VM and OS versions but we cannot flag these as reference platforms without significant community support for testing them.

Internationalization

Orion supports internationalization through plugins which provide message catalogs of translations. There is an NLS Plugin to aid developers in creating an initial message catalog. In addition, the folders, files and contents of the Orion Server have been verified to work with DBCS characters and the editor itself also supports BIDI. Orion as provided via Eclipse downloads will only provide English strings in the 1.0 release.

Table of Contents

Compatibility with Previous Releases

Compatibility of Release 1.0 with 0.5

Orion 1.0 guarantees no formal compatibility with Orion 0.5. While some plugins designed for Orion 0.5 may continue to function when installed in Orion 1.0, there may be changes to APIs and library functions used by the plugin that have changed in incompatible ways that prevent it from installing or operating properly.

Table of Contents

Themes and Priorities

The plan items listed below were defined according to contributor requirements and community feedback. Each plan item covers a feature or API that is to be added to the Orion project deliverables, or some aspect of the Orion project that is to be improved. Each plan item has its own entry in the Eclipse bugzilla database, with a title and a concise summary (usually a single paragraph) that explains the work item at a suitably high enough level so that everyone can readily understand what the work item entails.

Not all plan items represent the same amount of work; some may be quite large, others, quite small. Although some plan items are for work that is more pressing than others, the plan items appear in no particular order. See the corresponding bugzilla items for up-to-date status information on ongoing work and planned delivery milestones.

The current status of each plan item is noted:

  • Committed plan item - A committed plan item is one that we have decided to address for the release. In bugzilla, this is reflected by having a concrete target milestone assigned.
  • Proposed plan item - A proposed plan item is one that we are considering addressing for the release. Although we are actively investigating it, we are not yet in a position to commit to it, or to say that we won't be able to address it. After due consideration, a proposal will either be committed or deferred. In bugzilla, such items are reflected by having a target milestone "1.0" or "---" assigned.
  • Deferred plan item - A reasonable proposal that will not make it in to this release for some reason is marked as deferred with a brief note as to why it was deferred. Deferred plan items may resurface as committed plan items at a later point. In bugzilla, such items are reflected by having a target milestone "---" assigned.

Language Tooling

In Orion 0.5 several plugins utilized the Esprima parsing framework. This framework is included now as part of Orion however more recent versions are required to finalize on committing a more complete error tolerant version. There may be investigation on server side assisted content assist but this will not be made a committed item for 1.0.

  • Committed
    • Improved error recovery in JavaScript Parsing Leverage work done to make the Esprima parser capable of error recovery. Waiting on a newer version of Esprima before this code can be contributed into Orion [Client]
  • Proposed

    None at this time.

  • Deferred

    None at this time.

Platform

This theme includes currency with the existing 3rd party libraries used and providing existing and new core features that are modular.

  • Committed
    • Finalize i18N support Also provide examples on how to integrate with new plugins and how to use the NLS tool [Client]
    • Word Wrap support in Editor This is a requirement for many projects [Client]
    • Variable line hight in editor This is desirable for many usecases [Client]
    • Persona login capabilities Provide the capability to login via a Persona ID [Client][Server]
    • Default Crawling Search for File Implementations Provide a default crawling search engine for new file system implementations. At a minimum supporting files for Ctrl-F [Client]
    • Improve Workspace naming conventions Currently the displayed names look like garbled text vs. User IDs [Client][Server]
    • Improved specification for Plugin Model Plugin Model and Architecture for describing, identifying, discovering and installing. Support plugin catalogs via a feed as well as page redirection. Finalize the plugin lifecycle and include the capability to disable a plugin without uninstalling it. [Client]
  • Proposed

    None at this time.

  • Deferred
    • Plugin license agreements Provide the ability to display and acknowledge plugin licenses [Client]
    • Plugin Packages Provide a means to install a group of plugins together[Client]
    • Offline modes Investigate solutions to migrating to an offline mode to continue development while disconnected [Client]
    • Syncronize settings Syncronize local storage and user preferences [Client][Server]
    • REST API for Git Command Line Add Git support to the Orion Console. In order to do this Orion needs REST APIs for Git.[Client][Git][Server]

User Experience

In 0.5 the Orion UX was a significant focus. Alignment across pages on selection models, layout, etc is almost complete. This will be finalized before 1.0 ships. In addition the team will look at how theming can be accomplished.

  • Committed
    • Local credential caching Provide credential caching for current page to aid in Git authentication [Client]
    • Finalize on Orion UI Consistency (This was not fully completed but much work was done in this area) Finalize on consistency of page layout, section, selection throughout default Orion pages.[Client]
    • Improved Git Squash and Pull support Support for Git squash and better pull support for fixes[Client][Git][Server]
    • Universal Client side diff Provide universal diff for any two files using client side code only [Client]
    • Improved Admin page The current Admin page takes too long to load [Client][Server]
  • Proposed

    None at this time.

  • Deferred
    • Navigator in Editor outline view Investigate a navigator within the outline view for the Editor [Client]
    • Add Themeing Capabilities Investigate streamlining our style sheets and potentially provide styling capabilities through the use of less. Also provide default styles and a style picker to allow the use to control the look of certain Orion elements.[Client]
    • Analyze and improve Git page performance[Client][Git][Server]
    • Vector Based font for Icons Create and replace existing bitmap fonts with a Vector based design. This improved rendering on newer high resolution displays.[Client]
    • Vector Based font for Icons Create and replace existing bitmap fonts with a Vector based design. This improved rendering on newer high resolution displays.[Client]
    • Move plugin service display to console Move service descriptions from plugins page to the console. For developers to have a look at the services for a particular plugin. The plugins page is more for end users.[Client]

Infrastructure

This theme describes build or infrastructure issues not really surfaced in the client but essential to a good platform.

  • Committed
    • Dynamic System messages Provide an easy method for displaying system messages or information on the server without requiring a server restart. [Client][Server]
    • Finalize User Accounts Finalize on user account information required and authentication methods. Provide a backup method of retrieving old OrionHub accounts and data before purging for a 1.0 release [Client][Server]
  • Proposed

    None at this time.

  • Deferred
    • Improve the test coverage and capabilities. Investigate JavaScript code coverage tools to see if there are ways to report on the completeness of the current testing. [Releng]
    • Finalize GetPlugins location The Github location for the current plugins is convenient but doesn't show association with OrionHub or Orion in general. Should the plugins continue to exist there or moved to a location with a deeper association to Orion.
    • JSLint Clean Go through JavaScript code and ensure all files are JSLint clean. Many files were authored in Eclipse which does not have the same JSLint capabilities as the Orion editor.
    • Clean up unused code and files Finalize directory structure for 1.0 shape and remove any unused files and code fragments.
    • Source Maps for Debugging Source maps debug support for our build. Improves debugability for optimized pages.

Table of Contents

view raw xml of project plan
from project meta-data key "projectplanurl"