Let’s assume for the moment, that in an alternate reality I can travel back in time to 2008. Once there, I meet a bright bunch of people that work on something called e5 (executive summary.odp). My summary:

“the runtime platform that is simple and appealing to _____ application developers”

Here’s what I would say to them:

e5 should take risks

When I became interested in Eclipse it was cool and disruptive. A real game changer. It is now the established tooling platform and understandably locked into perpetual refinement mode (Entrenched Player’s Dilemma). Make sure that e5 is equally game changing. Otherwise we are setting ourselves up to be disrupted.

At the EclipseCon 2008 we committed a “strategic sin”. We agreed that e4 would be compatible with 3.x. This limited the potential for e4 by forcing it to be something that is “in the box” vs. “outside the box”.

(taken from Death by risk-aversion by Kathy Sierra)

For e5 to be successful it needs to take risks. I don’t think that we need a better tooling platform. We already have a very good one with 3.x. And it’s still improving and not going away. Instead we need a runtime that provides something unique and remarkable. It must kick-ass in a new way.

e5 needs a driver

If you try to be everything to everybody, you will at best be mediocre at everything. e5 should be laser focused on being the best runtime for ___________ developers.

People tend to avoid specialization. It is perceived as a risk. However, if you ask a marketing person he / she will tell you that specialization is good. It’s your way to get noticed. It’s your foot in the door. You build a niche, become unbeatable and expand. Eclipse 3.x first became the tooling platform of choice, then client platform of choice for Java devs, then the modeling technology of choice for Java devs.

Unfortunately e4 lacks a driver that would help it specialize and focus. A driver, like the JDT was for the Platform. As far as I know, there is no major product build on top of e4. I believe that the current e4 (Feb 2010) is not yet appealing enough for web development or client development. It will not lure web-side Java developers away from Spring / J2EE / GWT. Or client-side Java developers away from RCP. Or Javascript folks away from jQuery / Prototype / Dojo. Or Rubyists away from Rails.

It is hard to pick the right driver. I don’t want to attempt providing an answer and limit your thinking. But feel free to share your thoughts in the comments.

e5 must be easy to learn & master

If you believe Eclipse 3.x is easy to get into, attend a beginner’s training. You will see how experienced Java developers struggle with the learning curve. And it’s not becoming easier with e4.

That is a problem, because it limits the mass appeal of Eclipse as a runtime solution. If you think it is a popular runtime, go to a Java User Group and see how few of the people who use Eclipse have written a plug-in for it.

It is in our human nature, that we tend to take the path that has the least resistance (read: easy) not the path that offers the most rewards (read: complex technology).

For e5 to be broadly successful it must kick-ass AND be easy to learn & master.

Looking forward to your comments,
Elias.

Tags: e4

The RAP team just announced the availability of RAP 1.3 M5!

If you’re interested in single-sourcing Eclipse-based applications, please give it a try.

In the 1.3 M5 release, the RAP team added more SWT API to make single sourcing existing applications easier:

• Composite#layout( Control[], int )
• MouseEvent#stateMask
• Widget#reskin( int ) and SWT.Skin event
• ImageData
• ImageLoader
• ImageLoaderEvent

The team also added IApplication support which simply translates into one less extension point you have to use to create a RAP application. In the past, RAP had its own entrypoint extension point which performed a similar role to what the application support does in Equinox already.  This should make RAP even easier for RCP developers to get into.

RAP is also taking advantage of the Equinox extension registry is able to handle multiple locales.

So please give RAP a try if you’re interested in bringing your RCP application to the web.

Tags: eclipse rap, rap

Image credit: So gesehen@flicker, CC BY-SA 2.0.

I have been playing around with e4 (M3+Integration) today and so far I’m not impressed. I’m keeping an open mind, and may change my opinion at a later time.

At the moment however,  I would dare to say that e4 might be the “Windows Vista” moment for Eclipse. High hopes, but at the end of the day not groundbreaking enough to be interesting for a wide audience of developers (=regular java devs, web devs)

There are some things I like a lot and would like to see in 3.x, such as:

• CSS theming
• trident animations
• getting rid of the *Advisors

The biggest drawbacks in my opinion:

#1  NOT simpler,  just different

From my POV app development is still too complex for the avarage developer.  Here is why:

• Using dependency injection via annotations instead of having interfaces / abstract classes makes it very hard for beginners to figure out how to write classes. It is not obvious what annotations are available at any given point (@Inject, @PreDestroy, etc). The type hierarchy does not help for finding similar implementations – since there is no hierarchy
• The e4 workbench designer for the workbench model (.e4xmi) is nice, but unstable (failed to load my simple example). Editing the .e4xmi by hand or a tree-like emf editor is cryptic and less user friendly than the plugin.xml editor
• The plugin.xml is still necessary. So with the .e4xmi file we now have two .xml files that are relevant. I would like to see just one or none.
• Still too many technologies to master: Extension Points, OSGi, Workbench Model, EMF, Annotations, SWT, JFace.

“Simplify the programming model” is stated as e4’s first objective (e4-summary.odp), but  I don’t think this is true at present.

#2 Still big and intimidating

I often hear the Eclipse is big, bulky and intimidating. The Eclipse e4 download packs 230 MB and all the UI clutter we are used to – but many newbies find confusing.

#3 No killer feature

If a customer asked me about migrating to e4 for a product that launches in Q4 2010, I couldn’t really recommend it. At this point I don’t see any “must have“ features yet — especially for the folks that have 3.x apps up and running.

This is bad and a bit of a catch-22 situation:

• Without some “must have”  features people are going to stay with what they already know (3.x) instead taking the risk of using something new
• The longer people wait to use e4 the longer it will take to reach critical mass and a high level of maturity (i.e. most bugs found)

Looking forward to your opinions – especially if you disagree.

Kind regards,
Elias.

Tags: e4

We proudly present Riena 2.0 M5 – the first release in the 2.0 stream.  As you can see by the long New & Noteworthy, we have been very active in last six weeks. Read on for my five favorite new things:

1. Pluggable Marker Decorations

The new BorderMarkerSupport draws red-borders around a widget and replaces the standard ControlDecoration. You can select either error decoration style via the Look-and-Feel settings.

2. Enhanced Master/Details Widget

The Master/Details Widget automatically links a table with the details area on the bottom (or top). It is used heavily by some of Riena’s consumers. As a result we have been receiving good feedback and have added several requested features on this milestone:

• nicer border (includes button area, separates table from buttons with a single line)
• API to participate in the life-cycle (before / after selection, apply, remove, new)
• API to ’suggest’ a new entry – it will show in the details area and Apply will enable
• API to tweak the margin and spacing of the Master/Details widget

3. Image Button Widget

The SWT Buttons have a system-defined look that is hard to customize (for example the background color cannot be changed). Riena’s ImageButton Widget emulates a button using three images (standard, hover, pushed state).

4. Multiple Default Buttons per Controller

Riena’s Controllers have a new API that supports several default buttons per controller. The default button has a blue glow when enabled. In that state it will automatically be pushed when the user hits ENTER (anywhere).

5. Controller Testing

Controller testing is now very straightforward and has been decoupled from the UI (widgets). Just subclass AbstractSubModuleControllerTest to get started. In addition your controller has to use the new API getRidget(Class, String) instead of getRidget(String). The package org.eclipse.riena.client.controller.test in the org.eclipse.riena.tests bundle has several examples.

Read the New & Noteworthy for additional details on these items.

Tags: helios, milestone, riena

Here’s a gentle reminder that OSGi DevCon London 2010 is happening in a few weeks.

I highly recommend registering if you’re interested in OSGi. There will be people from all over the OSGi community including some great tutorials. I’ll be giving a talk regarding OSGi and API evolution… with some stories of how we handle the problem at Eclipse, how it’s handled elsewhere and what are the gaps. I’m also excited about the OSGi Development Tooling Panel that Christian Dupuis, Peter Kriens, David Savage, Toni Menzel and I will be hosting. If you were looking at a time to connect (or praiseand lambast us) with some of the OSGi Tooling folks, this would be a good time. We’re hoping for a lively and friendly discussion.

Feel free to check out the schedule online for the full listing of talks and tutorials.

I hope to see you there.

Tags: OSGi

Eclipse 3.6 M5 is now available for download. There are lots of new and exciting features, like the ability to open and file directly from the command line.  You can also use the synchronize view to compare patches:

Debug also introduced a few new features (like instance counts):

Check out all the new features in the New and Noteworthy.

Download the milestone:
http://download.eclipse.org/eclipse/downloads/drops/S-3.6M5-201001291300/index.php

or use p2 to upgrade to it:

http://download.eclipse.org/eclipse/updates/3.6milestones/

Tags: helios

Today we formalized some changes in the Eclipse Series of books. Some time ago Lee Nackman left IBM and his various roles related to Eclipse. Many of you may not know Lee but he was instrumental in the early days of Eclipse and IBM’s ongoing contribution and commitment to Eclipse. Lee, Erich Gamma and John Weigand envisioned and created the Eclipse Series of more then 20 books that today conveys so much vital information to the Eclipse community.

I’m pleased to report that I am taking over Lee’s place on the Eclipse Series editorial board. One of my first tasks has been to help in the redesign of the series look. The result of that effort can be seen in the OSGi and Equinox book going to press this week.

The original series had a sequence of Eclipse photos. This was fitting and attractive. Unfortunately, many of the photos looked similar and as a result is was hard to distinguish one book from another. For the new look we have standardized on a new color scheme and layout. Different books will have distinct images largely at the discretion of the authors but the overall look will be consistent.

We have also introduced a subtle branding differentiation through the use of the Eclipse or EclipseRT logos (see the top left corner) depending on their focus (tooling vs. runtime).

In this new role I will be looking for new ways to drive the content that the community needs. Writing a book is a huge investment and while many teams have made very significant technical contributions, they are not big enough or well-funded enough to write books. There are a few ideas kicking around for how to lower the barrier and what topics are in most need of coverage. While we have  great wealth of new projects at Eclipse, the book pipeline is surprisingly sparse.

As with everything at Eclipse, the community can help. Your suggestions for formats, topics and indeed, content are more than welcome. Feel free to contact me directly or post comments on this blog.

Tags: books, eclipse, syndicate

After more than a year of work we have finally completed the entire OSGi and Equinox book. The text, artwork, index, front matter and now cover are done and will be off to the printer and a bookstore near you in the next few days.

The cover marks a departure from the original series style of Eclipse photos. The publisher and series editorial team felt that that theme had run its course and the wanted a new look. We are pleased to be the first book with the new look. Expect subsequent books in the series to have a similar upper portions with different main images in the lower half.

Note also the use of the EclipseRT logo on the upper right corner.

Books in the series will have either the Eclipse logo or the EclipseRT logo depending on their focus (tooling vs. runtime). The upcoming 2nd edition of the RCP book will be the second in the series to have the new cover style and the EclipseRT logo. We have not decided on the imagery yet though…

Happy reading…

Tags: eclipseRT, equinox, OSGi

Yesterday, the EclipseCon Program Committee made the final tough decisions and pressed the button to notify people if their submissions got accepted or not. I had the honor of putting together the Eclipse Runtime (EclipseRT) content.

If you’re coming to EclipseCon, you’ll have a great opportunity to learn about EclipseRT and OSGi.

Here are some of my favorite selections for runtime…

Tutorials

Getting Started with Eclipse RT
Build a Working OSGi Application
Building Server-Side Eclipse based web applications

Talks

Gemini – Helping Shape the Future of Enterprise Java
Composite Bundles – Isolating Applications in a Collaborative OSGi World
ScalaModules: OSGi the Easy Way with a Scala DSL

I hope you enjoy the program!

Tags: eclipseRT, equinox

Today, the Eclipse Foundation announced two new projects at Eclipse.org, Graphiti and Virgo.

The Graphiti project aims to offer an Eclipse-based graphics framework to enable easy development of state-of-the-art diagram editors for domain models. SAP plans to contribute the developed framework. This could have a large impact in the Eclipse Modeling space where graphic modeling is only getting better and better. The contribution is also important because SAP is showing that it’s strongly committed to the Eclipse ecosystem.

The Virgo project will provide a runtime platform for the development of server-side enterprise applications built on top of Equinox, and optionally using modules from the Gemini project. On top of that, the Virgo project solidifies the EclipseRT vision that a lot of us have been preaching for awhile.

Want to learn more about EclipseRT? Check out the whitepaper.

Another thing to note about the Virgo project is that tooling will be coming along but contributed to specific projects at Eclipse.

Developer tools that provide support for Virgo are out of scope for the Virgo project as part of EclipseRT. However, the Virgo team also propose to work with the existing WTP and PDE projects to contribute relevant developer tools for Virgo to those projects. These contributions will be based upon the existing Bundlor and dm Server development tools projects detailed below.

So far, it looks like three out of twelve zodiac signs are taken for OSGi related projects.

Which one will be next ?

Tags: eclipse, gemini, OSGi, virgo