November is over now and last week I attended the last DemoCamp for the year. In this year’s November DemoCamp series I spoke at three events and with this post I’d like to present you with some impressions.

Bonn, November 16th: The beginning…

It was the first DemoCamp that was located in Bonn ever. So, as a result of this the audience was not very big, although at least 40 people found their way to the demos. I was already familiar with most of the talks.  I’d seen both Marcel Bruch’s talk on the Code Recommenders project and Mathias Sohn’s talk about EGit before, but they are still interesting. Besides these talks, one highlight was the talk about Xtext from Karsten Thoms which I hadn’t seen before in this form. He demonstrated how easy it is to create a DSL with Xtext. It’s fantastic what people can do with Eclipse technology.

Afterwards we all met at the Stammtisch. The bad thing was that Ralph Müller had to leave the talks early because he wasn’t feeling well. (Just a note here that he left before the RAP talk, so it wasn’t the talk that made him sick)

München, November 23rd: Party time…

For me it was the first time speaking at the annual DemoCamp in Munich. The organizers are well known Eclipse folks: Jonas Helming, Maximilian Koegel and Ekke. The cool thing was that these guys were so good at publicizing the camp that 100 people decided to spend an evening watching the demos. One thing that I missed was the talk by Marcel Bruch. Marcel where were you? Despite Marcel being missing, there were some really good talks. Two examples are the e4 talk by Tom Schindl and the Mylyn talk by Benjamin Muskalla. Of course both talks have been given before but I still recommend listening to them. They’re great speakers. Of course the RAP talk was another highlight

To put it all in a nutshell Munich was one of the best DemoCamps ever.  It had a very friendly atmosphere with beer service during the talks (thanks Jonas) and a great Stammtisch afterwards. But once more Ralph missed it so I had to pay for my own.

Karlsruhe, December 9th: The return of Ralph…

The last DemoCamp I visited in this series was the Karlsruhe DemoCamp last week. And guess what?  Marcel Bruch was speaking there. Why was I not surprised ? In addition to his talk, there was a world premiere in the form of Markus Tiede from Bredex presenting Jubula, one of the most recently created Eclipse projects. It was really fun to watch the IDE program by itself. Some other good talks were given by Benjamin Muskalla and Karsten Thoms. I saw Karsten in Bonn and the good thing was, that he presented two different talks. Its really nice to see that some people invest the time to provide fresh talks to the audience. I think I need to create a new talk too

The same as with the other camps, there was a Stammtisch afterwards. And surprisingly Ralph Müller was there too. So, the first round was on the Eclipse Foundation. Thanks Eclipse Foundation! I’m sure he came because he wanted to give his 6 democamps tour a nice finish. Hope to see you on more Stammtisch’s next year, Ralph.

To sum up, it was a great month with a lot of traveling. I met a lot of nice people that are all involved in Eclipse in their own way:  some as IDE users, some as contributors, some Foundation folks and a few committers – the ecosystem in its pure form. So, I hope to see some of you again at EclipseCon next year where I hope I’ll also be able to show you Eclipse RTP.

Tags: democamp, e4, eclipse, jubula, rap, redview, tycho, xtext

Some of you might remember the Mars challenge back at the last EclipseCon? – well; it’s back.
Now that the Eclipse 4.0 SDK released, we ‘d like to introduce to you the revival of this challenge –  on RAP.

We re-implemented the e4 Mars Rover client, single sourced it using RAP and are now presenting the RAP Rover Challenge. We use our own server now and since we don’t have the original EclipseCon rover and arena we simply simulate those on client side using the data we get from the server. However old clients should be able to adopt to the new server using this URL: http://rap.eclipsesource.com:8081/server/ – with the slight difference that there is no picture sent by the server.

For those of you who have not heard of it, here’s how you use it:

You should simply visit the challenge site (or click on the screen shot below) and sign up for control. When you gain control, hit the targets and score points. Check out after if you were able to beat the current high score.

If you are interested in the e4 client code you can find that here.

Have fun – we hope you’ll enjoy our e4 + RAP showcase.

The original rover at the EclipseCon

The e4 mars rover client on the web

Tags: e4, eclipsecon, mars, rap, rover

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

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’re all looking forward to talk about EclipseRT, Equinox and RAP at the DemoCamps around the world. In case you want to catch us and talk about Eclipse and related topics, just join one of the DemoCamps near you. Besides many other interesting talks, we’ll mostly cover EclipseRT, RAP and p2.

Ottawa, ON, Canada – November 24 – Jeff McAffer (EclipseRT)
Braunschweig/Hanover, Germany – November 25 – Benjamin Muskalla (RAP)
Stuttgart, Germany – November 26 – Jordi Boehme Lopez (p2)
Kaiserslautern, Germany – November 26 – Holger Staudacher (RAP)
Frankfurt, Germany – November 26 – Benjamin Muskalla (EclipseRT,RAP)
Vienna, Austria – November 30 – Chris Anisczcyk and Jeff McAffer (RAP,EclipseRT)
Karlsruhe, Germany – December 3 – Markus Knauer, Benjamin Muskalla (EclipseRT)
Hamburg, Germany – December 4 – Jochen Krause (RAP)

I’m really looking forward to see you at the DemoCamps, as always it tends to be a lot of fun!

Tags: democamp, e4, eclipseRT, equinox, helios, rap, Single Sourcing, talks

Today, the Eclipse e4 project had its first 1.0 milestone release.

This is the beginning towards sprinting for the 1.0 final release.

The big new and noteworthy in this milestone is support for remote debugging of JavaScript and in particular e4 JavaScript bundles. The support is currently restricted to Mozilla Rhino, however in true Eclipse fashion, the JavaScript debug model and extension models are in place to allow supporting other JavaScript runtimes.

If you’re interested in Eclipse e4, here’s some resources:

• e4 whitepaper
• Mike Wilson’s blog post on the future of Eclipse
• e4 wiki
• e4 webinars

Enjoy and please consider contributing to the e4 effort!

Tags: e4, helios, javascript, milestone

I recently blogged about the OSGi EventAdmin service and got some good feedback. I like to inform people of some more things that came to light about EventAdmin. First, I added a template in PDE for the OSGi EventAdmin service that will make its debut in Eclipse 3.6 M3:

It basically uses OSGi Declarative Services to register an EventHandler that listens for the bundle started event topic by default:

org/osgi/framework/BundleEvent/STARTED

Hopefully this should make it easier for people to get started with OSGi EventAdmin.

Second, Scott Lewis from the Eclipse Communications Framework (ECF) team has a distributed version of the OSGi EventAdmin service implemented. If you want to get at the code, check out the ECF wiki.

Finally, the Eclipse e4 project (the next generation of the Eclipse platform) is somewhat interested in the OSGi EventAdmin service. There’s been discussion on a bug around the general problem of model eventing and how to avoid the ‘listener hell’ problem we had with the old platform.

Tags: e4, ecf, OSGi

I recently had a few people come to me to chat about the OSGi EventAdmin service. For those who are curious, the EventAdmin service is part of the OSGi Compendium Specification and allows you to publish and listen to events via a pub-sub system. I’ll try to do a quick write up on how to actually use the service. As with any OSGi service, the first and foremost thing you need to do is acquire the EventAdmin service. There are many ways to do this, but I prefer to use Declarative Services these days. This is what a sample component definition would look like:

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" 
   immediate="true"
   name="org.eclipse.example">
<implementation class= "org.eclipse.example.MyClass"/>
<reference bind="setEventAdmin" interface="org.osgi.service.event.EventAdmin"/>
</scr:component>

Once we acquire the EventAdmin service, there are really two things you can do: publish and listen for events.

Publishing Events

To publish events, you need to pick a name for your topic. For example purposes, let’s pretend we wanted to publish information about memory events. A good topic name for this would be something like:

org/eclipse/equinox/events/MemoryEvent/{NORMAL,SERIOUS,CRITICAL}

If we wanted to publish a critical memory event, we have to create an Event object and publish it using EventAdmin:

...
Event event = new Event("org/eclipse/equinox/events/MemoryEvent/CRITICAL", null);
eventAdmin.postEvent(event);

It’s important to note that there are two ways of sending events using EventAdmin. This depends whether you want your event to be sent in a asynchronous our synchronous fashion. In the example above, we used the postEvent(...) method in EventAdmin which sends events in an asynchronous fashion. To send events in a synchronous fashion, EventAdmin exposes the sendEvent(...) method so we could simply change our code to send event synchronously:

...
Event event = new Event("org/eclipse/equinox/events/MemoryEvent/CRITICAL", null);
eventAdmin.sendEvent(event);

An additional thing to note is that you can send additional properties with your events as the Event object takes an optional Map parameter in its constructor.

Listening for Events

From the consumer side of things, we’re interested in handling the memory events. To do this, we need to register an EventHandler, let’s call it a MemoryEventHandler in this case:

public class MemoryEventHandler implements EventHandler {
 
	public void handleEvent(Event event) {
		// TODO panic... handle memory event
	}
}

Next, we need to register our MemoryEventHandler with the service registry with the proper EventAdmin topic name. There are many ways to do this, but for the variety purposes, let’s do it the traditional way in a bundle activator via a BundleContext reference:

...
EventHandler handler = new MemoryEventHandler();
properties = new Hashtable<String, String>();
properties(
   EventConstants.EVENT_TOPIC, 
   "org/eclipse/equinox/events/MemoryEvent/CRITICAL");		
context.registerService(EventHandler.class.getName(), handler, properties);

The important part of the service registration involves topic you’re interested via the EventConstants.EVENT_TOPIC constant. In the example above, we were interested in critical memory events so we used the proper topic:

org/eclipse/equinox/events/MemoryEvent/CRITICAL

If we were interested in all memory events, EventAdmin supports wildcard matching on topics so we could do this:

org/eclipse/equinox/events/MemoryEvent/*

EventAdmin also supports filtering via the EventConstants.EVENT_FILTER constant.

For the curious, the example above could have easily been done using DS:

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" 
   name="org.eclipse.example.memoryHandler">
<implementation class="org.eclipse.example.MemoryEventHandler"/>
<service> 
 <provide interface="org.osgi.service.event.EventHandler"/>
</service>
 <property name=”event.topics” value=”org/eclipse/equinox/events/MemoryEvent/CRITICAL” />
</scr:component>

That’s all it takes to listen for events!

EventAdmin in Eclipse

Cool, now that you know more about EventAdmin… how about using it in your Eclipse RCP applications? Well, I have good news as Equinox has a great implementation of EventAdmin available. Furthermore, as of Eclipse 3.6 M2, EventAdmin will ship part of the Eclipse SDK. If you’re not building on top of Eclipse 3.6 yet, you can simply grab the event admin implementation from the Equinox SDK downloads page.

Note: The example I described in this blog is something someone proposed be included within Eclipse.

Tags: e4, OSGi

With e4 0.9 out in the wild, we should think again about the goals e4 tries to provide. One of them was to reduce the gap between Desktop and Web – not only speaking of reusing widgets but also to enable the platform handle multi-user scenarios. While the core e4 team concentrated on eliminating bad smells like singletons, the RAP team worked on better support for single sourcing applications in general. With an experimental version of RAP which includes some features not yet in the current release, we were able to run the demo out of the box including the whole underlying infrastructure like the modeled workbench – without touching the e4 code.

If you take a look at the RAP Demos page you’ll find the e4 contacts demo running on RAP. If you want to try it out yourself or even help to contribute to this effort, take a look this wiki page. In case you’re interested what you can do with e4, be sure to participate in the e4 webinars.This week, there will be Part 2 with topics like RAP, the Compatibility layer and the flexible resources model. Looking at the questions that came up in the last RAP webinar and the first part of the E4 webinar, people seem to be very interested how e4 and RAP play together. I’ll try to answer the open questions during the webinar this week. Looking forward to a great event.

Tags: databinding, e4, rap, Single Sourcing, swt

Last week, the Eclipse e4 project had its alpha release.

What’s e4?

It’s simply the next generation of the Eclipse platform. The Eclipse platform team has learned a lot of lessons since the Eclipse project started and it’s time to experiment and innovate. There’s also a desire to involve more people at the platform level.

To get a better idea of where e4 is going, here’s some resources:

• e4 whitepaper
• e4 New and Noteworthy
• Mike Wilson’s blog post on the future of Eclipse
• Register for e4 webinars
• e4 wiki

If you’re interested in the project or the future of Eclipse, the e4 team would love to hear from you.

The first general release of e4 is expected in 2010.

Tags: e4