Eclipse Orion – what’s next after 1.0?
A month on from its initial arrival, Eclipse Magazins Diana Kupfer sat down with project lead Ken Walker to discuss its impact and the next moves for Eclipse Orion
We’ve been monitoring the progress of Eclipse’s
browser-based IDE spinoff Orion eagerly for some time now. After
months of milestones and tinkering, the team shipped
Eclipse Orion 1.0 bang on October’s
Now with a solid base nailed down, thoughts turn towards the
next major release, 2.0, in February. By the looks of
this week’s opening milestone, a lot of
effort seems to be going towards a node-based Orion
Eclipse Magazin’s Diana Kupfer sat down with Project Lead Ken
Walker to talk more about the web-based IDE and what else is in
Orion 1.0 was released just about a month ago.
Congratulations! Was this difficult or has development gone
smoothly so far?
Walker: The Orion team managed to ship on time each of our
pre-releases in February and June of 2012 and meet our October goal
of shipping a 1.0. Having a 1.0 release so soon after a summer
where developers are supposed to be relaxing was the most
challenging aspect, but the team really pulled together and we’re
all quite proud of what we have running at OrionHub.
A basic, but important question: why do they think that a
browser-based IDE is superior to a desktop one?
Walker: Many developers spend a significant time downloading
their IDE, finding and setting up the plug-ins required for their
current development task. If they head home and decide to work on
their iPad while commuting by train or otherwise and have no access
to their pristine setup, they’re pretty much out of luck. Orion
envisions a scenario where developers can set up their workflows
around projects which combine resources, libraries, repositories
and deployment scenarios to get their tasks done. Each of these
tasks and their associated plugins are combined client side in the
browser, from wherever you are accessing Orion.
Obviously, Orion has come a long way since last year, and
the features/improvements of the past year are difficult to put in
a nutshell. Still, what are your personal top five new 1.0
Walker: A new look and feel for our UI. Significant work was
done to make Orion a more compelling place to code, free from the
clutter of a standard IDE, but still customizable through themes.
We still have a lot of work here, specifically around the concept
of Projects but we believe we’re on a good trajectory. Inclusion of
breed library really helps in areas around content assist and
providing parse trees to plugins. Adding an extensible Shell for
command line zealots. Out of the box we provide basic capabilities
but this Shell can be extended by plugins to do things like
provisioning, or like we’re doing for 2.0, launching Node.js
applications. Improved Content Assist is a feature enabled by both
the Esprima parser and the Doctrine libraries, but we continue to
push on language tooling. Great Git Support. We completely
redesigned most of our Git pages, added dynamic loading to the UI,
plus added merge/squash and a very nifty code review
A year ago, Simon wrote about the four guiding design
principles of the Orion project in Eclipse Magazin: using native
browser capabilities, keeping it task-oriented/resource-focused,
being performant and lightweight and having low barriers to entry
for adopters. To what extent were you able to adhere to these
Walker: The Orion team has continued to meet these four
design principles through the 1.0 release. For the future, the team
is investigating the concept of Projects and this may add slightly
more information or context for a page but we don’t believe it will
cause us to digress from these guidelines. Adoption has been great
in the community. At EclipseCon Europe we were given many demos of
integrations that we weren’t even involved with. So it shows that
Orion is easy to adopt both structurally and though use of our
Scratch Pad, Style Editor and the use of the identity
system Persona are some of the results of the ongoing collaboration
with the Mozilla DevTools team. How, when and why did this
Walker: The collaboration with Mozilla began when Mihai Sucan
(from Mozilla) investigated the available web editors and decided
that the Orion editor was the only one that could support IME and
Accessibility properly because it uses the content editable support
from the browser.
So he approached us and started logging bugs and submitting
patches. The Orion team has also consumed both the GCLI for our
Shell and Persona as a login authentication because it’s extremely
easy to integrate and understand (it’s just your email address) and
also that it is managed by an Open Source group.
…and what other collaborative projects/components are
planned in the future?
Walker: Through 2012, Orion has had great collaboration with
committers from VMware. They are producing the Scripted editor for
desktop use, are consuming and contribution to Orion to achieve
their goals. There are also other Eclipse teams like Xtext working
on a cloud version of their tools and the Stardust project looking
to integrate their BPM tools as an extension to Orion.
Orion has had wide adoption apart from Mozilla. You must
have heard many reasons for this great interest in Orion – which
ones did you hear most often?
Walker: One of the main reasons for adoption is the leading
edge approach to extending the platform through plug-ins right in
the browser, vs. having to do this only on a server. The team has
done this in a secure manner and it’s very easy to write an
extension to Orion. The Orion editor, completely written in
provides the framework for content assist, highlighting,
validation, among other features like i18N support.
Part of your plans for the 2.0 release in February is to
work on deployment solutions because OrionHub
is not going to be the hosting provider. Any specific plans
Walker: That’s not completely what we meant, we mean that
OrionHub is not funded to the level where it should be considered a
corporate hosting site. OrionHub is a testbed of our milestones and
release candidates. What we want to work on is getting code out of
your Orion site onto hosted sites through as many supported means
that we can. This also includes looking at a Node.js based server
that as a simple node package manager install, can provide live
editing, debugging and running of a Node app on whatever platform
you have running node.
Same for offline support – how will this be
Walker: Offline support will require leveraging client side
caching and app-caching to the full capabilities of modern
browsers. We already support an HTML5 local file system, so the
content can be made available offline, but offline could also
leverage a small Node.js based solution offering access to your
whole or a sandboxed portion of your file system.
What else is particularly noteworthy regarding the 2.0
Walker: There are at least two features that are major
changes to Orion in 2.0. The first is the introduction of a Project
concept. A Project will be the aggregation of resources, libraries,
repositories and actions for tasks such as deployment. While we
won’t be able to get all the Project features we want in 2.0, we’ll
have a start on this idea by February. The second major feature is
support for Node.js. This doesn’t just mean supporting writing Node
apps, but actually porting portions of the Orion server to Node. At
the moment we have the capability to use the node package manager
(npm) to install Orion and that’s all that is required. You start
Orion and you can edit, install plugins, and launch Node
applications wherever your Node runtime is located be that on your
desktop or on a Raspberry Pi.
Do you have enough developers to achieve your next goals or
are you looking for help?
We can always use more developers. Working in an Agile manner
with short delivery time frames, it would be easy to onboard new
developers. There is a real uptake in the community and we’re
seeing an influx of pull requests for bugs. The team has been
marking our bugs as “help-wanted” indicating these bugs are
excellent candidates for newcomers to Orion.