Today I did a talk at the EclipseCon 2011 which was entitled “Eclipse Runtime out-of-the-box“. With this talk I introduced the EclipseRTP project. So, if you missed it here are the slides 
Today’s a great day. The Eclipse Foundation accepted the proposal for the RTP Project. RTP stands for Runtime Packaging. And here’s what it’s all about.
Marcus Baker wrote an article called “Install Me“, which was published in the book “97 things a programmer should know“. On two pages he shows the reader exactly how important the first minutes are when a new user tries to get familiar with your software. He argues that it is the responsibility of the software developer, to make it as easy as possible for the user to see that your software is what he needs.
Currently we don’t do a good job with this at EclipseRT. There are several EclipseRT technologies out there and every one provides an individual starting point for new users. From my point of view, changing this would bring EclipseRT a big step further.
That’s the inspiration behind the RTP project. All that a user should have to do is download – install – run. The idea is to create one or more common starting points that new users can use to get familiar with EclipseRT technology. Once we have the installation accomplished, we’ll have to convince the user with good examples and documentation. Investigation shouldn’t take more than 5 minutes. If the user doesn’t see what he needs in his first five minutes, the software will not get a second chance. There is also the chance of course, that the annoyed user might spread the word that the software doesn’t do the job right. So, its definitely worthwhile to invest in keeping new users happy.
And this is what RTP is all about: working with as many EclipseRT projects as possible to provide a really good out-of-the box experience for new users. If you are interested in this project please let me know. We welcome all help towards succeeding with RTP. If you want to learn more about RTP there are also two EclipseCon 2011 submissions (submission 1, submission 2) you can read.
Two days ago was the Helios DemoCamp in Darmstadt at Deutsche Telekom. I think it was a very successful evening with a whole bunch of good talks. Two of them are very noteworthy.
The first one was presented by Marcel Bruch. He talked about the Eclipse Code Recommenders project which he’s working on at TU Darmstadt. The basic idea behind this project is to provide a way to recommend code. He used the analogy of the Amazon online store. When you buy a book you always get a recommendation along the lines of, “People who bought this book also found this one interesting…”. The Code Recommenders does exactly the same just with code. Watch the great screencast the Code Recommenders Team provides if you don’t want to take my word for it.
 |
 |
Another especially noteworthy demo for me was presented by Stefan Lay. He demo’d the Eclipse Git Team provider called EGit. In addition to the tooling he presented Gerrit. Gerrit is an automated review tool for Git. The scenario he presented was to push some changes to a remote repository. The changes were caught by gerrit to be reviewed. With those changes however, an automated build failed and gerrit sent an automated message that the changes couldn’t be applied because they broke the build. I think this will make the workflow much easier for code review and keeping the repository stable. The EGit project already uses Gerrit for their productive work.
 |
 |
To put it all in a nutshell it was a very cool DemoCamp with 120 attendees and nice buffet afterwards. At this point I want to thank Ralph Müller and the Foundation who organized a spontanous Eclipse Stammtisch after the DemoCamp. It was great to talk to all the guys individually. The bad thing about this is that the evening went by too fast. But there also a good thing. Most of those people will also attend the Eclipse Summit Europe in November and we can meet again.
 |
 |
As part of the new Eclipse Helios, the Rich Ajax Platform project released version 1.3. If you’d like to know what is new in RAP 1.3, here’s a short screencast.
You can find a more detailed version on the RAP 1.3 New and Noteworthy page.
Thanks to the community for all the hard work that made this great release possible.
Of course, we are currently making plans for RAP 1.4, which will be part of Indigo. Therefore, we started a discussion on the plan items on our newsgroup. We’re looking forward to another great year with Indigo.
Based on your feedback on my last blog posts, I’ve implemented a first prototype of the RAP protocol. Here’s an update on the current state. Several functions are now implemented e.g. server side message creation, client side message processing, client side message creation and server side message processing. The cool thing about all this stuff is that it works already with the RAP lifecycle. To demonstrate the use of the protocol, I migrated the Shell widget. You can see the results in the screenshots below.
The first screenshot shows the protocol based shell. You can see that FireBug is open and is showing the JSON response from the server. The second screenshot shows a JSON request that was sent from the client to the server. The current protocol implementation is a hybrid, which means that it uses JavaScript and protocol messages. With this hybrid it’s possible to run the RAP workbench on top of the protocol based shell.
If you want to test this shell yourself you can use the RAP protocol git mirror which can be found on github. At the github wiki you can see what bundles you’ll need to run the protocol based shell. To start the protocol shell just run the launch configuration within the org.eclipse.rap.rwt.protocol.playground bundle. The code for the protocol is in a very early state, so please be warned that there could still be drastic changes in the code base.
The next step in the development of the protocol will be to test it on a different client technology. For this purpose a demo for the iPad would be the perfect candidate. AdLib is a JavaScript library which brings native like widgets to the iPad’s mobile safari browser. And, I think it will be possible to use this library with RAP and the protocol. I will keep you posted on the progress of the iPad demo. Looking forward to your feedback.
As I described in a previous blog I’m going to create the tooling for creating equinox based war files within this year’s gsoc. For this purpose I created some UI sketches with the WireframeSketcher. You can see the first thoughts on the UI below. I would appreciate if you can give some feedback on the sketches to improve the tooling. You can find more information about the war products at the wiki page.
I finally had the time to care about one of my outstanding tasks – provide a tutorial and example how to use Equinox Security. While the tutorial was initially targeted for RAP users, I also added a launch config and a target definition for RCP as the code is the same for both runtimes. The tutorial will provide some hints and pointers how to setup your login procedure, like shown below:
After logging in (hint, hint), you’re able to inspect the currently active Subject. I made up this example to be as simple as possible to demonstrate the key concepts of Equinox Security, and not the ones from RAP/RCP.
As I said, you can either choose between RAP as runtime (above) or RCP (below).
In addition to the authentication mechanism, I wrote a pretty simple LoginModule to show how to connect your authentication process to an alternative backend (eg. LDAP, Kerberos, …).
As I put the tutorial into the Eclipse wiki, I encourage everyone to extend the tutorial with hints, tricks or ideas what you can do with Equinox Security. Hope the tutorial helps to get up to speed how to use secure your RCP/RAP applications.
Ever been to Mannheim? If not – this is your chance to visit this lovely city. For the Helios release, the guys behind the majug² (Mannheimer Java user Group) invite everybody to the Helios Democamp in June. And as Ian already found out: Yes, we love our DemoCamps! It’s always great to have technical discussions over a frosty beverage!
Watertower by flamouroux
At the moment, the attendee list is still pretty empty but save yourself a seat while it’s not booked out – they only have 100 seats available. Topics this year include EGit, EclipseRT, Android and Roo. Do you think a cool topic is missing? Step up and give a demo about what you’re doing! I’m really looking forward to see more demos of how people use Eclipse as IDE or runtime.
Hope to see you there for another great DemoCamp and ad-hoc Stammtisch!
I have to admit, I’m a little nervous what happens with the RAP community after this post. At least for me, the last days were pretty exciting. Some days ago, Ivan from the RAP team committed the initial support for a GC (GraphicsContext) for RAP. Currently restricted to the Canvas widget, the GC provides thousands of new use cases for RAP applications. The work by Ivan and Tim is just gorgeous and will help many developers to single-source their applications with even less exceptions. In case you want to try it out in this second without reading further, just fire up the RAP Examples demo and draw something yourself 
Credits for the picture above goes to Holger with the aim to come up with a new RAP project logo After using the GC the first time in the Examples demo, I thought about other possibilities to test the new GC. My first thought: custom widgets? Tired of writing custom widgets in JavaScript? Get your Canvas and single-source your custom widget with RCP by writing an owner-draw widget. But as it was late in the night, I decided to just reuse some existing owner-drawn widgets like those we can find in the Nebula project. After getting the PShelf widget from CVS, it was only a matter of seconds until I started my first RAP application using an owner-drawn Nebula widget:
And I think I know what most of you are currently thinking – Draw2D, GEF and GMF on RAP? To keep it and short and simple: No! While it may be possible to single source Draw2D with the exisiting Canvas, I’m pretty sure it will not scale. The way Draw2D is implemented will cause major performance problems with the browser-side Canvas widget. As I said, it may be possible but not really preferable. For supporting Draw2D the right technology on the client-side is there. Only on the server-side we would need APIs that entirely hide the GC. Thus we could directly translate from one vector-based technology to the other.
I’m pretty excited to see how the community can profit from the new Canvas implementation. Want to try it out? Either get the current RAP runtime from CVS or wait some days until we can publish RAP M7 (which has several other cool new & noteworthy items).
Even though I’ve been involved in the Eclipse community for around 5 years, I’m still amazed by the projects that are hosted under the Eclipse umbrella. As an “insider”, I have a pretty good overview of many projects and at least a rough picture of all the other cool stuff. While I love working with EclipseRT technologies like Equinox, RAP, EclipseLink, ECF or <insert your project here>, I always find myself in the same situation. This stuff is awesome but do users really get the point of what’s possible? Learning a new technology is always hard, but if you want to develop enterprise-ready, scalable and vibrant platforms using Eclipse components, there are so many obstacles to overcome. You need to have at least a clue about OSGi/Equinox, Extensions and their corresponding Extension points (for each for your consumed modules) and many other things. I don’t want to say that Eclipse is too complicated (which is a topic for another post anyway), but what I would really like to see is a better way to get our future consumers up to speed. As Esther Dyson once said:
A worker’s paradise is a consumer’s hell.
With the Eclipse Examples project we wanted to provide a few exemplary projects to show how to use different projects. In theory a nice idea, but practically I don’t see that this effort was very successful. Wayne and me discussed some ideas back in 2008 but without a concrete outcome. Thinking about this topic after EclipseCon, my current thought was to provide easy ways for our consumers to try out the bits and pieces of all the projects. What I constantly run into though, is that you need to do so many things before you can get started, like setting up a target platform, making your examples depend on the right bundles, using the right extension points/services/etc, creating launch configurations. Many projects already helped themselves by providing examples using PDE templates. That’s the way I’d like to tell newcomers how to get started and would push this even a little further – the idea is to provide some infrastructure in the Examples project to help others setting up their examples. The projects just provide example bundles, maybe a target definition, a launch configuration and a cheatsheet or something. In the end, the user should be able to try out another Eclipse technology within 2 clicks: New Example > That technology, run!
Basically PDE already provides many of these things but it’s not yet at the point I would love to see it. It’s still too complex for consumers to create target platforms (I know what I’m talking about), create their launch configs and get started with the examples. While there are still some hurdles to jump, I think our users and consumers would thank us for getting them up to speed in seconds. It should even be interesting for non-OSGi related examples as other projects thought about something like this for years. I don’t see a chance to have this ready for Helios, but I’m pretty confident that we could do something like this in the timeframe for the I… release train. Would other projects be interested in such an approach to distribute their examples? Please leave a comment on this bug if you do so to collect ideas, wishes and requirements.
(18) (4) (120) (57) (8) (58) (127) (35) (9) (15) (3) (17) (12) (13) (12) (16) (3) (20) (8)