Tags: protocol, rap

There are a lot of very good reasons for developers to get on board with Open Source Software (OSS). Businesses are making use of OSS both because of the cost savings and the excellent quality of the code (not to mention the open development model which makes it very easy for them to get involved). Whether you are student looking for your first job or a senior engineering looking at the strategic direction for your company, open source can play a key role in your career.

When I talk to people about OSS I’m often asked, “How can I get involved?“. One of the first things you can do is to start filing bugs. Of course, ranting about missing features or writing vague bug reports that nobody can understand doesn’t help. But if you notice something wrong with your favorite open source software, why not file a good bug report?

So why am I bringing this up today?  For those of you unfamiliar with the Eclipse development process, this Friday marks the feature freeze for Eclipse 3.6 (at least for the platform).  After this Friday, the developers will be focusing on regressions and other serious bugs for the next 6 weeks or so.  On Monday – Tuesday (April 26 – 27) most Eclipse committers will be working through a pretty serious 2 day test pass. This test pass will help us determine what serious bugs need to be fixed.  If you’re building your business on Eclipse technology or you just happen to use Eclipse as your IDE of choice, spending a day of your time helping to test Eclipse is likely time well spent.

I spent today working through a number of p2 UI tests.  If you’re interested in helping out, download the latest Eclipse Integration Build (look for the builds starting with an I.  At the time of writing, the latest IBuild is I20100426-0852).   If you’re on IRC, you can join #eclipse-dev or #equinox-dev and we can point you at some features that need some testing.

Tags: helios

Finally the voting process for this years Google Summer of Code is over and they announced the accepted students. I’m really happy that so many interesting proposals got trough and really looking forward to see the outcome of all the student projects.

Here is the full list of the proposals that got accepted for 2010.
Improve Eclipse Git integration
Student: Dariusz Luksza
Mentor(s): Matthias Sohn

WAR deployment for RAP/Equinox based applications
Student: Holger Staudacher
Mentor(s): Ruediger Herrmann

Theme editor for RAP
Student: Benjamin Muskalla (IRC: benny`work)
Mentor(s): Ruediger Herrmann

Rich Editor For Wiki Markup
Student: Harshana Eranga Martin
Mentor(s): David Green

index based model compare match engine
Student: Stefan Leopold
Mentor(s): Cedric Brun

Restlet integration with Equinox
Student: Rajeev Sampath
Mentor(s): Bryan Hunt

C++ editor enhancements
Student: Tomasz Wesolowski
Mentor(s): Alena Laskavaia

DNS-SD based wide-area ECF discovery provider
Student: Markus Alexander Kuppe (IRC: lemmy)
Mentor(s): Scott Lewis

Hudson Integration for Mylyn
Student: Markus Knittig
Mentor(s): Steffen Pingel

Google Wave ECF provider
Student: Sebastian Schmidt (IRC: sebs)
Mentor(s): Mustafa Isik

Integrate GMF runtime with Mylyn task focused UI
Student: Yongming Luo
Mentor(s): Mariot Chauvin

Congratulations to all the students and a big kudos to the organizers and mentors for their choice. As every year, it is pretty difficult to dismiss so many other good proposals but there were only 11 slots available this year for Eclipse. Looking forward to a great summer!

Tags: ecf, egit, emf, equinox, gmf, google summer of code, hudson, mylyn, rap, restlet, wave

From time to time, I’m in the situation when I want to suggest a UI change or even try to come up with a completely new UI. While I love programming, it may be easier in these situations to just “sketch” the idea instead of really getting your feet wet. As many people asked me what I use for UI sketches, I thought I should share it with you – the tool is called WireframeSketcher. It’s “just” an Eclipse plugin to create sketches pretty easily. As most of the UIs in my life are SWT-based, WireframeSketcher comes with one absolutely cool feature – turn an existing dialog into a sketch. Fire up any dialog, hit the magic “Alt+Shift+F5″ and you’re done. Is it that easy? Yes – I really love it. Here is an example of the Import Wizard which I also used in my latest blog post to further modify it with my ideas.

Not only is it easy to operate, it also has pretty good Eclipse integration and you always find the things where you expect them (eg. select and button and you can modify everything in the Properties View).

As Eclipse commiter, you can get a free licence of the plugin or you can buy the plugin from the author if you want to use it commercially. Either way, give it a try the next time you want to mock a new UI prototype.

Tags: eclipse, eclipse ui, sketch, swt, tips, ui, wireframesketcher

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!

Tags: android, democamp, eclipseRT, egit, equinox, git, helios, roo, talks

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).

Tags: canvas, draw2d, eclipseRT, gef, helios, nebula, new and noteworthy, rap, Single Sourcing

Here’s a nice Helios feature that comes in handy when you often work with multiple workspaces simultaneously (as we recommend for developing single source application with RCP and RAP). If you do, you probably know this which-is-which guessing when looking at your taskbar (or window switcher):

How can you distinguish your Eclipse instances? How can you tell in which workspace you are editing? There is a commandline parameter -showlocation that appends the workspace location to the window title – not very helpful either. Now since Helios M6, you can give your workspace a name in the Workspace preference page:

This name is then displayed in the window title:

Much better, isn’t it?

Tags: eclipse, helios, Single Sourcing

At EclipseCon I had the pleasure of presenting an introductory tutorial on p2 with an awesome co-presenter Kim Moir.

The tutorial went well, although we did have a few technical problems at the beginning. We knew there was way too much material to cover in a 3 hour tutorial, and if we started cutting it down then we wouldn’t get to the advanced material (which 1/2 the people want to see). If we started with the advanced material then we would loose the other half of the audience.    So either way, 1/2 of the room will be disappointed.  We decided to shoot somewhere in the middle and make the tutorial available as an Eclipse plug-in. This way, if you need a little more time, you could work through it at your own pace. If you are a p2 wiz, then you could whip ahead and take an early lunch.

If you couldn’t make the tutorial, the plug-in is available here as a p2 repository. The tutorial was designed to work with Eclipse 3.6 M6, so you will likely have to download that version of Eclipse. Once you have Eclipse 3.6 M6, simply open Help->Install New Software…

1. Enter http://download.eclipsesource.com/~irbull/p2-tutorial
2. Make sure you UN-CHECK GROUP BY CATEGORY!
3. Select p2 Tutorials Tools

Once installed, you can open the view called RCP Book Samples Manager (our plug-in was based on the famous samples manager from the Eclipse RCP Book).

You can use the samples manager to move between the different parts of the tutorial. You can even compare the solution to the start to see exactly what you have to do for each task.

If you have questions or feedback on the tutorial, please don’t hesitate to contact me at irbull (at) eclipsesource (dot) com.

Tags: eclipsecon, p2

EclipseCon was very good this year. The new venue and some new format ideas seemed to work. It was a lot more intimate and easier to spot people. Lunch was packed but that made it harder for people to sit isolated in their own little group (that’s a good thing).  Moreover, the talks were very good. I made a concerted effort to go to more talks and was well rewarded. It seems that others were as well.

One of the great things we’ve been doing for a few years now is the talk voting.  Simply by dropping a card in one of three buckets as you exit the talk you can signal a +1, 0 or -1 for the talk. You can also leave text comments which the team collects, transcribes and eventually distributes to the speakers.

The talk voting results were put up on the EclipseCon site recently. There are a number of interesting points.

• Of course, Jeff Norris’ keynote got rave reviews. Nearly 300 people cast their +1 for the talk and not a single -1.  Surprisingly three lost soles voted 0. Not sure what what it would take to get their approval but…
• We don’t know the full number of people at each talk but based on the keynote responses, it seems like roughly 50-60% talk attendees vote. I figure there were about 500 people at each keynote and there were 250-300 votes in each. Not sure if that translates for the smaller sessions but its a data point. Would be good to get the voter turn out up next year. I mean, you’re right there…
• Of the over 6500 votes cast, only ~7% of attendees did not like (-1) the talk they went to and over 70% were very pleased (+1) with what they saw. That is pretty impressive with such a varied group.
• About half of the talks received no -1 votes!

I was particularly pleased to see that the OSGi Best Practices talk I did with Paul, Martin and Chris was well received (111 +1′s, 8 0′s and no -1′s).

We were less lucky on the OSGi tutorial.  72% where very pleased but a few (4%) were disappointed and the rest were, well, ok with it. We’ll have to see what the write-in reports say. For sure the room was packed and there were a few issues getting setup and running. Seems par for the tutorial course but still not satisfactory. Perhaps next year we can do better both on the setup and structure but also on the facilities.

In any event, another great EclipseCon done.  Everyone involved in running the show and presenting should be proud.  Thanks for all your hard work. Well done.

Tags: eclipsecon

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.

Tags: consumers, eclipseRT, equinox, examples, OSGi, p2, pde, rap