Twitter github

Posts Tagged with “pde”

Happy BugDay!

Here’s just a reminder that Eclipse BugDay is upon us again. I actually managed to participate this time around and fix an issue in Mylyn that bothered me to no end. If you have time in your day today to go through some bugs, please do so. Here’s some interesting ones from PDE:

  • [154206] – Ensure that bin.includes does not refer to the source
  • [199098] – [Schema][Editors] Duplicate names are allowed from source page
  • [208742] – NLS of WorkspacePluginModelBase only works if resource is called plugin.properties

Good luck bug squashing!

Plug-in Versioning and PDE

When working on Eclipse, you get spoiled as a developer with certain things. I for one, get spoiled silly with the wonderful Java development environment provided by the JDT.

However, another thing I get spoiled by is plug-in versioning. Eclipse actually has versioning guidelines that are reasonable and pretty well followed within the Eclipse Platform. It’s not like where in certain experiences, I’ve known people to make up versioning guidelines without any respect to API and just rev the version when you release, whether things have changed or not. In essence, plug-in versioning is something I believe should be taken seriously and well thought about it before slapping something on (or just leaving the version empty like most people do).

To help with plug-in versioning, I recently dropped code in the next I-build based on an old bug that I had time to hack while on the long plane ride. Here’s the use case…

You’re trying to version a plug-in and open up the properties dialog:

That’s not too helpful… sure you can specify the versions but you aren’t really sure what you’re developing against. Here’s how it looks like after the patch:

Now you can see the versions available in your target and workspace. If you select the ones you’re interested and click match, it will properly construct the minimum and maximum versions:

So, let me know what you think. Also, this means no more excuses when setting up your dependencies and versioning plug-ins, OK :)?

PDE Does Singapore

Well, I’m off on my Asia adventure today. This involves being on a plane for 24 hours but, I think it will be worth it once I get to talk Eclipse and plug-ins at JAX Asia next week. My offer of discussing Eclipse over a frosty beverage always stands if anyone is in the Singapore area 😉

A long trip on a plane for me can only mean one thing, productivity. I plan to squash some Eclipse bugday bugs on the plane ride, one of them being one of my favorite Eclipse pet peeves: wizards that suffer from amnesia. I also plan to work on some new articles that will discuss some plug-in development best practices that I’ve learned over the years and touch on some aspects of PDE that aren’t understood well (ie., the target editor, automated management of dependencies, plug-in search, etc…).

I’ve also been looking over EclipseCon submissions for the tracks I’m chairing. It’s going to be really tough to choose the long talks… there’s a lot of good submissions with not many slots to fill. There’s also some really good short talks and tutorial submissions this year. Why do you guys have to make it so hard :(?

On a side note, if you’re interested in a rich text editor in Eclipse, voice your support on this bug which aims to make the sexy editor out of the EPF project consumable for third parties. In case you want a sneak peak at the editor’s features, Philip Beauvoir has already done some work in this area to make the editor consumable in an RCP application.

Remember to rock the vote on Eclipse bugs you care about 🙂

Have you submitted something to EclipseCon?

EclipseCon 2008 is closing submissions on Monday, November 19th so there’s not much time left to submit something. The PDE team has submitted its annual plug-in development tutorials:

Being on the EclipseCon Program Committee, I’m going to do my best to try something new this year with the tutorial order. I’m thinking that the introductory Plug-in Development tutorials done by the PDE team should take place in the morning. In the afternoon, there will be a tutorial on eRCP followed by one on RAP. This effectively would allow a tutorial attendee to get a taste of three different runtime environments that Eclipse targets:

  • Desktop (RCP)
  • Embedded (eRCP)
  • Server (RAP)

Where else can you do that? This also traces the evolution of Eclipse from just being some tooling platform to a viable runtime for various types of applications. It’s my hope that the tutorial attendees who went through this track of tutorials would come away that Eclipse isn’t just about tools anymore and that there’s a lot of power in reusing your skills and assets to develop against three different runtime environments. All of this in just one day!

Do people think this is a good idea? If so, I’ll see what I can do to make it happen.

Oh, and please submit something to EclipseCon if you haven’t already 🙂

Plug-in Development 1.0.1.qualifier

Brian Bauman and I from PDE will be giving a webinar in late January so please mark your calendars!

I really wanted to name the talk ‘Plug-in Development 1.0.1.qualifier‘ but I don’t think the target audience would get it…

For the webinar, Brian and I want to keep everyone happy so we are splitting the webinar into three parts. For the first part, we will spend some time covering the basics of using PDE for plug-in development. The second part will include some advance aspects of PDE… things like the Target Editor… Automated Management of Dependencies… etc…. For the finale, we will include some best practices, tips and tricks that we have learned through the years of developing plug-ins. We will then open the floor for questions.

So, please tune in in late January!

Pushing Pixels

Can you see what’s wrong with this picture? Most people can’t. Only a few people like Kevin McGuire who like to nitpick and subscribe to the religion of color can spot the problem quickly. I call these people pixel pushers. In my opinion, these are the people that make Eclipse look good due to their attention to detail.

Now getting back to what’s wrong, here’s a hint:

Oh my eyes! When I saw this it hit me like a ton of bricks and I had to fix it immediately.

Why does this happen? Well, there’s the unfortunate situation when Eclipse Forms sections are given text clients with things like toolbar managers to add cool icons. This results in text clients taller than their title text so things grow accordingly causing adjacent sections to possibly not align. If you would like to learn more about this problem, check out this unpublished article on some new things in Eclipse Forms 3.3 by one of my favorite people in Toronto, Adam Archer.

Here’s how it should look like:

Ah, much better!

What’s the fix? Align adjacent sections using the text client height difference:

section2.descriptionVerticalSpacing = section1.getTextClientHeightDifference();

Does this make me a pixel pusher too?

Plug-in Spy, RCP and Eclipse 3.3

I’ve been asked a few questions about the Plug-in Spy (ALT+SHIFT+F1) but haven’t had time to reply, but now I do so here’s my chance.

Does the Plug-in Spy work in RCP?

Yes, but you’ll miss out on the fancy hyperlinking… instead all classes are resolved to their fully qualified name. Outside the normal RCP set of dependencies, the spy depends on org.eclipse.ui.forms which is fairly minimal and is probably in your RCP application already. Here’s a quick screenshot of the famous RCP Mail example from PDE with two extra dependencies added (org.eclipse.ui.forms and org.eclipse.pde.runtime which contains the spy):

Does the Plug-in Spy work in Eclipse 3.3?

It should, it doesn’t depend on anything from the 3.4 code base. I’d just build your own copy of the spy from HEAD and export it using the PDE wizards.

Does the Plug-in Spy work in Eclipse 3.2?

No, it takes advantage of some things found in the Platform Command Framework which made its debut in the 3.3 version of Eclipse. In theory the spy could work in 3.2, but it would require a rewrite and that’s something I’m not interested or have time for right now. There are bigger fish to fry in PDE at the moment to make plug-in development truly a first-class experience.

Happy spying!

Contributors and PDE 3.4M3

Eclipse 3.4M3 is coming out soon and with that, I thought I’d offer everyone a sneak peek at what’s going on from the PDE side of things. However, before I do that, I’d like to mention that for the first time, PDE had more bugs fixed from contributors than committers. So I first like to thank the following people for their contributions this milestone:

In terms of what was done for this milestone, let me show one of my favorite ones:

It’s now possible to refactor extension points and have it automatically update referencing extensions found in the workspace. This was a bit painful before if you had to do it by hand and happened quite frequently to me because I’d define an extension point like thing and forgot to pluralize it into things.

For the rest, you’ll have to wait until Friday 🙂

Disabling Bundles

The PDE and Equinox Framework teams have been busy graduating a concept of enable and disable for the runtime.

What does this mean? Well, bundles can essentially be disabled and prevented from starting due to some reasoning. This concept is very useful to the security work that is going on in the Equinox incubator. To help test this concept, the OSGi console was enhanced to support some new commands (enable/disable):

I also decided to polish up the Plug-in Registry view in PDE to enable power users to do some advanced bundle-related operations:

As a power user, don’t be a stupid power user and stop/disable some important bundles in your runtime instance 🙂

On a side note, if you want to help PDE improve the Plug-in Registry view even more, I filed an enhancement regarding exposing a Diagnose action similar to what is available in the OSGi console.

Greatbugs

Kim Horne reminded me today about greatbugs. I don’t know if Eclipse contributors know this, but it brings us committers such joy when a bug comes with detailed steps to reproduce, a patch and a test case. It’s a trifecta of bug squashing goodness.

It saves committers a ton of time if there is an easy way to reproduce the problem and a solution attached. In PDE, we recently filed a bug to do some refactoring around project operations and in the back of our minds thought that this type of stuff would never get addressed. Lo and behold, Les Jones contributed an excellent patch and test case to boot for the enhancement. Les will make his way to the PDE Hall of Fame soon 🙂

On a side note, Ian Bull (PDE Incubator committer) squeezed in an enhancement for 3.4M3 today. It will now be easier to work with your launch configurations when dealing with thousands of bundles. By the way, someone should hire Ian, I hear he’s finishing his PhD soon and I will be personally devastated if he doesn’t find a good job.