Twitter github

Reflections

It’s going to be 2008 soon so it’s a good time to reflect on what happened in 2007 (before the egg nog gets to me) and what we should be looking forward to in the future.

2007 Highlights

Interesting Times

There were other many cool things that happened this year (like an Ada project), but this is all I can quickly come up with in my head. I’ve also managed to put over 115,000 miles of air travel on my belt this year which is quite amazing given that I’m not a consultant who reads Getting Drunk in First Class daily.

On a serious note, we need to start looking to the future as I believe Eclipse is at a point where it needs to make a leap from 3.4 to 4.0 or we may live in a world where there’s no well-defined modularity or plug-in goodness. My main mission next year is not to become like those SmallTalk guys who reminisce in the days of how awesome SmallTalk was. There will be no reminiscing, Eclipse will stay awesome 🙂

Next Year

  • Eclipse 4.0
    • The effort should be started next year after Eclipse 3.4
    • I want to see community involvement resulting in a diverse “platform” team
  • Eclipse 3.4.3 or 3.5?
    • When we make the leap to 4.0, what happens to everyone on the 3.x train?
    • How do we not alienate current and future consumers of Eclipse?
  • 1000 Eclipse Committers
    • There are currently about ~900 Eclipse committers
    • We will reach 1000 next year, but will we be a “diverse” 1000?

Looking Ahead

I have a few challenges next year for myself to help Eclipse grow. These are things I also view that should be critical to the future adoption of Eclipse… so here they are:

  • Themeability
    • It’s too hard to theme Eclipse applications. A common complaint from peers and consultant friends is that they spend way too much time on making their Eclipse application look like ITunes or just less “IDE-like.” IBM Lotus spent time inventing its own custom CSS skinning technology for its platform when it shouldn’t of really had to. In the end, Eclipse is really missing out on growing a community of artistic people. Imagine browsing something like the Winamp Skins section but for your RCP applications?
  • Symmetrical Applications
    • By symmetrical applications, I mean applications that can run on various targets. By targets, I mean things like desktops (think RCP), web browsers (think RAP) and embedded devices (think eRCP). This what the word “tier-less” means in the Runtime Project Top-Level Project draft charter.
    • One of Eclipse’s greatest strengths is the adoption of OSGi technology which enables Eclipse to work on various targets. This is something we should push heavily when we start thinking about Eclipse 4.0 in my opinion.
    • The tooling around symmetrical applications needs work and something PDE should focus on in the future. If you ever tried to write an application that runs on RCP, eRCP, RAP using the same workspace, you’ve attained a level of Eclipse nirvana and pain that very few people have experienced.
  • Scripting
    • As a first step, it needs to be easier to script Eclipse to do things. I know we have the Eclipse Monkey, that’s a great start but we should also focus on things like allow plug-ins to be defined in different languages, like say JRuby. I know we have started some basic work in this direction, but it’s something that deserves more focus next year.
  • Diversity
    • Diversity is what makes us special and Eclipse needs to improve its diversity. There are shining examples of projects that have great diversity within Eclipse (like Modeling) but we need to focus growing it in other places. When I say diversity I mean many things. Whether it’s the diversity of committers on a project or the diversity of the types of project themselves (e.g.., embedded, automotive, web, …)

Ok, that’s my last brain dump for the year. It was a great year for Eclipse and I hope we can continue the fun next year. I appreciate everyone who reads and comments on my diatribes, thank you.

Happy Holidays everyone and see you next year!


  • AlBlue

    Perhaps also a less project-focussed workbench as well? Projects have been with us since 1.0 and despite having one of the highest voted bugs, the ability to have nested projects still isn’t there. And don’t forget the other end of the spectrum; the simple TextPad/EditPlus/WordPad replacement, with the ability to edit files anywhere on disk and react to a user double-clicking on a file externally.

    It’s also a high time to change the default text encoding to UTF-8 for all text-based files, too. Sadly, that will never happen, and nor (I suspect) will any of the other changes that are needed to drag Eclipse kicking and screaming into the Century of the Fruitbat.

  • AlBlue

    Perhaps also a less project-focussed workbench as well? Projects have been with us since 1.0 and despite having one of the highest voted bugs, the ability to have nested projects still isn’t there. And don’t forget the other end of the spectrum; the simple TextPad/EditPlus/WordPad replacement, with the ability to edit files anywhere on disk and react to a user double-clicking on a file externally.It’s also a high time to change the default text encoding to UTF-8 for all text-based files, too. Sadly, that will never happen, and nor (I suspect) will any of the other changes that are needed to drag Eclipse kicking and screaming into the Century of the Fruitbat.

  • Eugene Kuleshov

    Alex, since Eclipse 3.3 you can in fact create nested projects on the file system. Though logical structures supported by JDT don’t reflect that hierarchy and only allow to declare project interdependencies.

  • Eugene Kuleshov

    Alex, since Eclipse 3.3 you can in fact create nested projects on the file system. Though logical structures supported by JDT don’t reflect that hierarchy and only allow to declare project interdependencies.

  • David

    A couple of other items:

    * Move PDE and JDT to the tools project. If eclipse really is a platform, then seperate the JDT and PDE to tooling so that there is a clearer distinction.

    * Migrate all Menu interfaces to org.eclipse.ui.menus extension point. This makes it much easier for plugins to contribute functionality through menus to existing editors without having to modify the existing code base.

    * Migrate the WST Tools XML Source Editor into the platform or somewhere it is more generally available. This way we can consolidate down to one common XML tool instead of having PDE’s own editor, ANT’s own editor, WST’s editor, etc.

  • David

    A couple of other items:* Move PDE and JDT to the tools project. If eclipse really is a platform, then seperate the JDT and PDE to tooling so that there is a clearer distinction.* Migrate all Menu interfaces to org.eclipse.ui.menus extension point. This makes it much easier for plugins to contribute functionality through menus to existing editors without having to modify the existing code base.* Migrate the WST Tools XML Source Editor into the platform or somewhere it is more generally available. This way we can consolidate down to one common XML tool instead of having PDE’s own editor, ANT’s own editor, WST’s editor, etc.

  • Nikos

    One other item :

    Have the ability to change language “on the fly” just like a theme.
    Restart the platform to do that is manageable but not really the best.

  • Nikos

    One other item :Have the ability to change language “on the fly” just like a theme.Restart the platform to do that is manageable but not really the best.

  • Julen

    You mean a not-backwards-compatible Eclipse 4.0? I’m all for it. I find the number of deprecated extension points, classes and methods to be overwhelming. It’s about time to clean it up, even if I’m in the receiving end too. I help maintain an Eclipse plug-in (QuantumDB at sourceforge), that is running about since the early times of Eclipse. And we would have to do a lot of work to keep it to an hypothetic non-compatible 4.0. Still, I think it would be worth it. The current state of things has to break sometime, because you cannot keep adding complexity to the system indefinitely. So the time may well be now, as many concepts have crystalized in the latest releases that were fuzzy or non-existent when the first Eclipse API was designed.

  • Julen

    You mean a not-backwards-compatible Eclipse 4.0? I’m all for it. I find the number of deprecated extension points, classes and methods to be overwhelming. It’s about time to clean it up, even if I’m in the receiving end too. I help maintain an Eclipse plug-in (QuantumDB at sourceforge), that is running about since the early times of Eclipse. And we would have to do a lot of work to keep it to an hypothetic non-compatible 4.0. Still, I think it would be worth it. The current state of things has to break sometime, because you cannot keep adding complexity to the system indefinitely. So the time may well be now, as many concepts have crystalized in the latest releases that were fuzzy or non-existent when the first Eclipse API was designed.