Project Plan For Orion, version 2.0
Last revised 14:00 ET November 12th, 2012.
Please send comments about this plan to the email@example.com developer mailing list.
This document lays out the feature and API set for the next feature release of the Orion project after 1.0, designated release 2.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.
The release deliverables have the same form as previous releases, namely:
- Source code release for all Orion project deliverables, available as versions tagged "R2_0" in the Orion project Git repositories.
- Packaged Orion server download for Windows, Mac, and Linux
- Hosted Orion server on http://orionhub.org
Release milestones will be occurring at roughly 6 week intervals, followed by a short end-game consisting of three release candidates.
Our target is to complete 2.0 by end of February 2013, in concert with the EclipseCon North America 2013. 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.
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:
- Client target environments Indicates environments supported for end users of Orion-based web applications.
- Server target environments Indicates requirements for the platform where the Orion server is installed.
Orion 2.0 is tested and validated on the following reference client target environments:
|Internet Explorer 10.0|
|Red Hat Enterprise Linux||6||Chrome|
|Apple Mac OS X||10.8.2||Safari 6.0.2|
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 2.0 release of the Orion server is developed and tested on Java SE 6.
There is work underway to additionally support a purely Node.js based Orion environment. The reference platform for this work has not yet been established but will be made by the end of the 2.0 release
The Orion 2.0 Java server is tested and validated on the following reference server target environments:
|Windows||7||x86 32-bit||Oracle Java 6 Update 29
IBM Java 6 SR9 FP2
|Red Hat Enterprise Linux||6||x86 32-bit||Oracle Java 6 Update 29 (needs to be updated)
IBM Java 6 SR9 FP2
|Apple Mac OS X||10.8.2||Universal 64-bit||java version "1.6.0_37"|
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.
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 2.0 release.
Compatibility of Release 2.0 with 1.0
Orion 2.0 guarantees no formal compatibility with Orion 1.0. While most plugins designed for Orion 1.0 may continue to function when installed in Orion 2.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.
The incompatibilities will be documented in the Orion help system and on the Wiki
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.
Orion needs to have no roadblocks for projects to consume Orion components. As such, there needs to be effort to reduce some of our 3rd party dependencies. In addition, the Orion core needs to be compartmentalized to allow projects or products to consume only the pieces they need to build a web site or platform. Other changes in Consumability are there for improved uptake of Orion features including the Editor.
None at this time.
- Reduce 3rd party depenencies At the moment there are dependencies which can limit Orion adoption. These dependencies will be removed. [Client]
- Deployment options from Orion source Some project and/or products need the capability to create a deployment or consumption scenerio from the Orion source. This task is to provide a function to specify which portions of the Orion source are required and produce a new source or deployment sub-tree. [Client][Server][Node]
- Concrete Delegated UI Examples Feedback on 1.0 included the lack of extensibility for any User Interface components (say a picker from a text editor command). This item is both fixing/allowing such extensions and providing concrete examples of how to do this for plugin writers. [Client]
- Improve Editor Capabilities There have been requests to increase the capabilities of the editor (multi-column editing support, content assist changes, additional extension points). The support for DBCS and BIDI will continue to be improved upon as well. Some of this was done for 2.0 including builds for the editor but additional items will be added to the 3.0 plan. [Client]
None at this time.
- Concrete Skinning Examples Provide examples of both skinning Orion to match an existing project deployment and also how to integrate Orion style pages from a 3rd parting into the look and feel of an Orion application. [Client]
In order to get adoption by web developers and site designers, there needs to be a focus on developer workflows. This will start with introducing the notion of Projects in Orion, and then how to transform these projects into a deployable artifact to a web site, or a hosting service for example.
- Introducing Projects for Orion Develop a container which represents the artifacts of a Project such as the source location, libraries it might require, and automated deployment workflows. Projects made progress however they will be continued on the 3.0 release plan [Client][Server]
None at this time.
- User interface changes for Project and Workflows Create a new landing experience after login showing current projects or how to create a new project. Create a sidebar for describing current projects, drives (storage), libraries (3rd party), and Deployment steps.[Client]
- Support actions for transforming project contents Inevitably, any project under development needs some amount of transformation before actually being deployed to a hosting service. This item is to cover the investigation and implementation of needed transformations such as copying, minifying, compiling, etc.[Client][Server]
- Node based Orion file system client Implement, using the Node.js file APIs a plugin to support browsing the filesystem on the Node.js host. Security should be considered. [Client][Node]
- Node based application launching, debugging and npm support Support for launching Node applications from within the Orion UI and providing support to assist in setting up debugging. Additionally, provide features to aid in npm function access. [Client][Node]
None at this time.
- scriptd investigation as Node side scripting based on events Investigage scriptd as a method of providing scripting functionality based on events. [Client][Node]
- Look into how to support Node on standard Java server infrastructure (OrionHub.org) The default application launching for Node applications for testing will be provided through a node.js Server implementation of Orion. However, there should also be the option to self host at OrionHub. [Client][Server]