For those who follow me on Twitter, know that I and Firefox don’t get along. I just want to browse the web, and Firefox just wants to eat memory and crash all the time. However, I was pleasantly surprised when Firefox crashed and offered me a chance to give feedback:

I was so thrilled at this opportunity and thought about doing something like this in Eclipse land.

Does it make sense for us to have a feedback agent? Do Eclipse-based products out there already have their own feedback agent mechanisms? Would we benefit from having a standard one at Eclipse that people could build on top of?

One problem we would have with this is how to manage all the feedback. However, Mozilla must have the same problem too because they have a ton of users. Who sifts through all the feedback. Is there some processing on the backend to make sure things get sent to the right place or flagged somehow?

In the end, I think this is a good idea as it provides an communication channel between the software you write and your users. Plus, I could imagine hooking up the feedback mechanism to a Twitter feed for comedic purposes.

Thoughts?

Tags: eclipse

Elias recently blogged about about the ‘OSGi for Eclipse Developers‘ presentation I gave. There’s been some commentary about Eclipse plug-ins not being OSGi bundles. It was mostly spurred by this slide:

What we were trying to convey with this picture is that the OSGi and Eclipse communities tend to argue over a name. In the end, it’s still the same thing. Let me repeat, an Eclipse plug-in is an OSGi bundle and vice-versa. If anyone tells you otherwise, they are lying. There are people that like to claim that since Eclipse folks tend to heavily use the Extension Registry (i.e., plugin.xml) that they aren’t a bundle. The Extension Registry is simply another OSGi service and really just a feature built on top of the wonderful OSGi service registry. The Extension Registry also runs on other OSGi frameworks like Felix (it can even run outside of OSGi if you want). It’s no different than the Declarative Services (DS) bundles or Spring DM bundles (well I guess DS is in the OSGi specification). The only issue that you have to watch out for when developing a bundle is being tied to a framework. In Eclipse land, we have some special manifest headers (e.g., Eclipse-BuddyPolicy) that may not work in other frameworks. This isn’t really an Eclipse specific issue, other frameworks suffer from the same fate if they invent manifest headers. It’s still an OSGi bundle in the end.

What have people experienced out in the field regarding this debate? Anything? Any ideas on how to make things better?

In the end, what we were trying to say that the communities need to stop bickering and focus on the goal of getting more people on OSGi:

Right?

On a somewhat related note, the more important message in that presentation was that services are dynamic and you need to get in your head. I know programming for dynamics is hard but you just need to remember that terrible Culuture Club song when you think of OSGi services… you come and go! Anticipate dynamics and use things like Declarative Services to make your life easier.

And now I can’t get that song out of my head

Tags: OSGi

I’ve been doing bundle development for a very long time so I have a lot of fantasies of how we can improve development workflows. One of my fantasies while working with my target platform has been to have it automatically provisioned to me based on some requirements. Well, I’m happy to report that PDE now supports provisioning your target platform from a repository (as of Eclipse 3.5 M7) which makes my fantasty come true!

What does this mean? Well, let me walk you through a short demo:

The first thing to do is to create a new target definition in PDE (File->New->Target Definition):

For the purposes of this demo, let’s create a empty target to work with the Eclipse Communications Framework (ECF):

Next, let’s add some content to our target definition and choose the ‘Software Site’ source:

Let’s point to the Galileo repository as that’s where the ECF SDK lives:

Once that happens and we set our target platform, PDE will resolve the target definition and download everything that is needed:

Tada! After waiting for the target to resolve and download, we have everything we need to develop against ECF!

What exactly is going under the covers here? Well, PDE now allows you to craft a target definition using p2 IUs from a software site (repository). Just as we selected ECF, we could be building another product that needs Riena and ECF so we simply select the Riena and ECF IUs. All software-site based target definitions now are managed by a p2 profile and share a local bundle pool in the PDE metadata area. These target definitions are now easily shareable with your colleagues. You simply have to craft a target definition with the right information and put it somewhere your colleagues can access it. One of the coolest things about this feature is that since we use p2, you can plug in any repository and things would work transparently. For example, if someone wrote a p2 connector to talk to Maven or OBR repositories, things would work transparently since everything is an IU!

Note that if you aren’t comfortable with people provisioning a target from a software site, you can choose the other sources for content (directory, features, installation) and ship a target locally or in a SCM (this was how things worked before).

In the future, you’ll continue to see closer PDE and p2 integration.

Hope this helps! If you have any bugs or suggestions, please file a bug.

Tags: OSGi, pde

I couldn’t resist reposting this great slide from Bernd’s, Chris and Martin’s presentation “OSGi for Eclipse Developers“. Check it out yourself.

Tags: eclipse, OSGi

There’s a bug open for ECF to figure out a better/real name for it’s implementation of RFC 119.  Soon, we’re going to have an online vote to decide the winning name…but I wanted to say that my favorite (given my frequent harping about reliability/failure detection in distributed systems) is comment #7. ..even though I don’t think it will/can win .

Please contribute any ideas for names to the bug…amusing or not.

Tags: OSGi, rfc119

In Eclipse 3.5, the PDE team has been hard at work improving the API Tools component. One of the new exciting features we have planned for Eclipse 3.5 M7 is comparing baselines. To compare an API baseline, simply right click an API Tools enabled project and select the ‘Compare With -> API Baseline’ menu option (I’m using an Eclipse 3.5 build with an Eclipse 3.4.2 baseline):

Once you do that, you should be presented with the ‘API Tooling’ view:

No changes have been found? Oh, that makes sense since the org.eclipse.ui.views.log bundle doesn’t contain any API. Let’s choose the ‘org.eclipse.osgi’ bundle which definitely should have some API changes in it:

Look at that! You get information about methods and types added!

Hope this helps! If you have any ideas on how to improve API Tools, please file bugs.

Tags: OSGi, pde

I was at JAX 2009 last week and I’ve had people email about my slides. I’ve posted them to SlideShare:

OSGi for Eclipse Developers

What’s New in Plug-in Development (Galileo Edition)

Enjoy and hope to see you next year!

Tags: eclipse, OSGi

Yesterday, I had fun investigating how to open “detached” views progammatically.

Click to watch:

http://www.screencast.com/t/5ku89HjBNs

You can find this on Bug #270212, where we are discussing how use this in Eclipse Riena.

Tags: detached views, eclipse ui, riena

In the traditional RCP development workflow, you find yourself self-hosting a lot. If you don’t know what self-hosting means, it’s simply the process of launching a new Eclipse instance and executing the bundles you were working on in your workspace. This works well as there’s no real deployment step, but what happens if you want to run what you’re working on inside your current running Eclipse (host)? Well, you could use the classic, “export, copy, paste, delete, restart” technique” but that’s not optimal and takes some time. How do we get around this? Well, in Eclipse 3.5, PDE has new functionality to directly export into your host.  To demonstrate this functionality, let’s create a sample project using the ‘Hello, World Command’ template:

Then let’s export into our host using a new option in the export wizard:

Once we export and apply changes, we should see the sample plug-in installed and running (check the toolbar):

To uninstall, simply go to the ‘Installation Details’ page via the About page:

Hope this helps! I also created a video of this workflow in case anyone is interested.

Tags: pde

20 Eclipse projects were accepted this year for Google Summer of Code and you can see the complete list here:

http://socghop.appspot.com/org/home/google/gsoc2009/eclipse

Congratulations to all the students!!!  This year we had close to 100 proposals, and I’m happy to say that many of them were very, very  well thought out, it’s too bad we could not accept more.  I encourage members of the Eclipse community to review the list and see if there are any that peak your interest. While each student has been paired with a mentor, the students should be working with the Eclipse community as a whole.  As Wayne and I chatted at EclipseCon it became clear — The code we get from the students in Great, but getting new students immersed in the Eclipse community is even more valuable.

For students, hopefully we will get them blogging about their work.  If any students (or mentors) wants access to the Eclipse SOC blog, send me a note. Or better yet, file a bug against PlanetEclipse.

Tags: eclipse, soc