Many Eclipse committers have been hard at work on the Eclipse Juno (2012) release. There are already many new features including a whole new workbench model.  While this is obviously an exciting time in the history of Eclipse, many of the long time IBM committers have been focusing on future — Eclipse Orion.  Eclipse Orion is a web-based tooling platform. While I’m personally not involved in this project for my day-to-day work, I’ve been exploring the possibilities it exposes. To help you get started with Orion, I thought I would share my experiences.  In this article I’ll show you how to use Orion to develop a simple web application. In future articles I’ll explain how to create both client and server side plugins, as well as how to host your own Orion server.

Why Orion?

Before we can answer this, let’s look back 10 years.  A decade ago Eclipse had just shipped 1.0.  While many people saw Eclipse as a great Java IDE (which it is), Eclipse was also a universal tool platform.  Eventually Eclipse became a platform for Everything and Nothing In Particular, but in December 2001 it was a general purpose platform for development environments with Java Development as one such exemplary tool (C/C++ development was added shortly afterwards).  Many people attributed the success and quality of Eclipse to the fact that the developers used Eclipse for their day-to-day work, a concept known as eating your own dogfood. This model ensured that the quality of Eclipse remained high since any regressions would immediately be seen.

Fast-forward 10 years and we are starting to see many software tools moving to the web. Services such as GitHub, CloudBees, Cloudant, YouTrack, etc… reduce your IT overhead by moving many of your tools to 3rd party service providers, accessible via the web. Also, many of our applications are exposing web-based front ends and developers are relying on tools such as FireBug and other browser extensions.  Since most ‘coding’ still takes place on the desktop using tools like Eclipse or TextPad, developers are no longer using the tools they develop.

Eclipse Orion intends to change this.  Eclipse Orion is positioning itself as a Tooling Platform for the Web, on the Web.  If you’re currently building Web-Based software, then Orion will be of interest to you.

Is Orion Replacing Eclipse?

The aim of Orion is not to replace Eclipse.  Orion provides another tooling platform — this time for the web.  Not everyone is doing web development and not everyone wants their tools on the web.  However, if you are spending more of your time in a browser, Orion might be of interest.

Also, Orion is an entirely new code-base. This is not Eclipse running in a browser.

Getting Started

The easiest way to get started with Orion is to look at OrionHub.  OrionHub (http://orionhub.org) is a public beta server of Orion.  Anyone can request an account, but keep in mind that the workspaces are cleaned occasionally so there is no  guarantee that your data will be persisted.

1. Request an Account

Go to http://eclipse.org/orion to request an account.

2. Login to OrionHub

Go to http://orionhub.org and login. Once you’ve logged in, you can access you profile and associate other accounts if you wish.

3. Create your first project

There are a few helpful links across the top of the page. To create you first project, select the navigator and choose New Folder. You can also clone a project from a remote git repository if you choose.

4. Upload an existing project

Initializr allows you to create a bare-bones HTML 5 site, and download it as a zip file. This means you can get started on a new fancy web project without all the boilerplate setup.  I decided to download a bare-bone site from JavaScript InfoVis Toolkit for my example since I was interested in creating a graph based visualization. Using Orion, you can upload this zip file and start working immediately.

This this is on the web, you can review my code as I work:

http://orionhub.org/edit/edit.html#/file/ST/Jit/Examples/ForceDirected/example1.html

5. Launch a site

To test / debug your web application as you develop it, Orion allows you to launch a site containing the newly developed project. You can develop in one browser tab, and test (and debug) in another one. This paradigm means that all your tools are in one place.  To launch a site, choose the ‘Sites‘ link and Create Site.

You can map your project to this site.  In my case, I created a site called irbullvisualization. Feel free to access it at:
http://irbullvisualization.orionhub.org:8080/Jit/Examples/ForceDirected/example1.html

6. Share your project

By default, a Git repository is created for all projects on OrionHub.  Of course, this is just a local git repository (local to OrionHub), but you can easily add new remote references and push your projects around. You can commit changes using the Git Status Page:

And push your changes to remote hosts using the Repositories View:

Conclusion

The Eclipse Orion project is still in its infancy. Unlike the Eclipse project — which was opened sourced at the same time as its 1.0 release, the Orion project is still in its pre 1.0 stage. However, you can get involved with the project, tryout the beta at OrionHub.org or download your own Orion Server.

In my next article I’ll talk about Orion Plug-ins.

Tags: orion

In the RAP framework, the widgets in a website are remotely controlled by the web server. The server does this by sending messages to the client in response to Ajax requests. Until now, those messages used to contain proprietary JavaScript that has been evaluated by the browser. Apart from the drawbacks of using eval to process server responses, this tightly couples RAP to its default browser client. The messages were so specific that only this client could understand them.

One of our goals for RAP 1.5 is to open the framework for alternative client implementations. After all, the messages from the server contain precise rendering commands that are not at all specific to JavaScript. Commands like “create a button with text ‘Ok‘, set its size to 190x25px, and place it at pos (23,42)” or “change the text color of the label with id ‘w47‘ to ‘#ff0000‘” can be rendered by any client that is able to create and manipulate widgets. It doesn’t have to be a JavaScript client, also clients written in other languages like Java or Objective C can implement it. Clients can render widgets with any UI technology, be it SVG or even a mobile device’s native widget set.

To allow for those cases, we exchanged the communication format with a simple predefined format based on JSON. With the M4 build published today, all responses from a RAP server are now plain JSON. This also makes the debugging much easier, since developer tools like Firebug display the structure of a message.

When designing the protocol, we took great care not to limit the exchange format to widgets. Instead, we created a generic synchronization protocol for any kind of objects. Objects are identified with a unique id, and every operation is related to a target object that is referenced by its unique id. There are different types of operations: one to create an object, one to destroy it, one to change some properties on an object, etc. Every message from the server contains a list of operations, besides some meta information.

You’ve guessed that we already have some prototypes for alternative RAP clients in progress. We’ll write about them soon…

Tags: eclipse, juno, new and noteworthy, protocol, rap

There have been a discussion about build naming conventions lately.  SNAPSHOTS, nightly, milestone, GA, maintenance, integration, stable, etc…

In both Nick’s and Mickael’s posts, I noticed a theme: all builds are the same. Of course when they are built, or the process by which the built artifacts are vetted may change, but the build process is the same for all build types: namely, take what’s in HEAD/Master/Trunk/Tip/Top/Main Branch, tag it and build it.

This isn’t the case for the Eclipse project. The Nightly builds are actually done differently from the integration, milestone, stable, and maintenance builds.

The build processes that Nick and Michael mentioned, assume that once something is in Master/Head, it’s ready to be released and the only other variable is release date.  The Eclipse process doesn’t assume this.  In fact, I can release a wad of changes the night before Juno ships and likely none of them will be in build.  This is because Eclipse requires explicit tagging of what you want built.

Here is how it works:

1. Development teams continually release stuff to master.  Each night master is built to ensure that nobody has introduced compile errors (or broke unit tests). This is not bleeding edge! This is not intended for anyone.  This is not similar to maven SNAPSHOTS.
2. When teams are happy with their work, they tag the bundle.
3. Integration builds happen weekly, and only what’s tagged will be built. Integration builds are similar to SNAPSHOTS, and can be consumed (if you want the most bleeding edge stuff).
4. This has recently changed, so instead of tagging each week, we merge (from master into ‘integration’). This means, what’s in master won’t necessarily be in a build each week.

I’m pretty sure I can hear the GitClub screaming feature branch, feature branch, feature branch. Why don’t you just use feature branches?

Please keep in mind:

1. Eclipse is over 10 years old, and predates Git.  Would you really do feature branches with CVS? (maybe)
2. The Eclipse build takes a while to complete:

• Let’s assume it takes 6 hours to build and run the tests (1/4 of a day).
• Let’s assume there are 10 teams (SWT, Debug, Workbench, PDE, JDT, UA, etc…)
• Let’s assume each team has 2 features on the go at all times: 20 feature branches
• Right now (for better or worse) a full Eclipse build, plus platform tests must run on the Eclipse build infrastructure
• So, if we had 20 feature branches that we had to build in sequence, it would take 5 days to build todays nightly
• Tomorrow’s nightly would start once that’s done!

Yes I realize some of those assumptions might be rather simplifying — maybe we could run the builds in parallel and off-load the costs to the hardware, but having a central build of 20 feature branches is still not feasible.  Also, some teams would likely want to combined builds (now build the SWT + Workbench feature branch together).

I know some people will head down the path of build restructuring (completely refactor the Eclipse build so developers can run them locally, thus removing the necessity for a centralized builds). We’ve heard this before many times.  Instead of suggesting this, sponsoring the effort (with money + people power) would be more helpful.  Also remember that Eclipse has successfully shipped on-time for the pat 10 years.  So, if you really want the team to change their process to the development flavour of the week, be prepared to show some evidence that process XYZ is better.

This was not meant to start a development war, but rather explain a bit about how the Eclipse build process works.  For better or worse, it’s what we have.

BTW, what do others do? Does everyone use feature branches and assume what’s in Master is ready? What did you do before Git (did you use branches for development in CVS/SVN)?

Happy Holiday’s Everyone!

As many of us start to get into the Holiday spirit, the Eclipse and Equinox teams have an early gift for you, Eclipse Juno Milestone 4.

Eclipse now supports Annotation based Null Analysis. (See Deepak and Ayushman’s posts for more information).

There are also enhancements to SWT (Tree Cursor)

And Equinox now supports Jetty 8 and Servlet 3.0

Checkout the  completely New and Noteworthy

or Download the Milestone and try it out yourself.

Eclipse Indigo is out and Eclipse Juno development is in full swing. That means it’s time to start thinking about the Eclipse release in 2013 (Only 18 months away). While development plans are still a far ways off, we’ve already started to collect ideas for the name.

Historically Eclipse has chosen names in Alphabetical order (Helios, Indigo, Juno), which brings us to the letter ‘K’. Since some alphabets don’t have the letter ‘C’, we could explore names like Kanada or Kookie Monster.

Of course, we can also go with villains from Star Trek like Klingon or Khan

I’m sure you’ll be much more creative than me.  If you’re interested in following this discussion, feel free to CC yourself on this bug:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=365965

 

Does TDD actually improve software quality?  Are good software developers an order of magnitude better than poor ones?  Do multiple code reviews reduce the number of bugs in the software?  Does your choice of language improve productivity? Do distributed version control systems increase the number of contributions?

Many software developers (myself included) have strong beliefs about many of these questions.  In fact, order a round of beers at EclipseCon and bring up any one of these topics and see what happens. Unfortunately, many of us base our arguments on our own experiences or anecdotes.  Occasionally we will quote some self proclaimed expert in the field and assume our argument is ‘proven’.  Is this evidence?

As tool developers — building the Best Integrated Development Environment — we need to hold ourselves to higher standards. We cannot be designing future IDEs based solely on what works well for me. If you have a few minutes, please watch the following video by Greg Wilson on Software Carpentry: Software Engineering Empirical Results. http://software-carpentry.org/4_0/softeng/ebse. I had the good fortune of meeting Greg a few years ago through the Canadian Consortium for Software Engineering. A much longer version of the talk is available (embedded below): http://vimeo.com/9270320.

Greg Wilson – What We Actually Know About Software Development, and Why We Believe It’s True from CUSEC on Vimeo.

I prefer the longer one as I think he makes a much stronger point about questioning beliefs.

This has been blogged about before by me and other guys, but as I still constantly experience this problem, a little repetition won’t hurt

In many projects you see the result of System.out.println() statements on the console: statements such as “here I am” or “this should not happen”. These are often left-overs from debugging sessions and flood the log. Although, I personally think there are almost no use cases where you would use sysouts over breakpoints or conditional breakpoints, you cannot just forbid the use of them. In fact, there are good use cases I know for sysouts, e.g. debugging drag and drop where you do not want the debugger to suspend on a drag over. However, polluting the code with sysouts should be a no go. A better solution is to put the sysout statement into the break point’s condition like this:

In this way you do not pollute the code and, if you want to persist your sysouts, you can export the breakpoints.