Chris Aniszczyk's (zx) diatribe

Eclipse 3.4M2 is coming out tomorrow so I figure I would give people a sneak peak at some of the PDE features for M2 (I can’t give it all away).

• Quickfix around access restrictions
• Problems with unresolved classes? PDE can help.
  
• Improved editor functionality (drag and drop in manifest editor, highlighting externalized strings in source editors)
  
• My little Plug-in Spy (ALT+SHIFT+F1) makes its debut. It may not be completely perfect yet, but it’s a good start at easing some significant pain in the Eclipse community. Look for some cooler features like menu sniffing in M3.
  

So, it’s been busy in PDE land this week. Plus, there’s a lot of excitement regarding Austin City Limits… I mean 130 bands… Bob Dylan… Bjork… Muse…

Here’s some items to keep people in the loop:

• The famous log view from PDE is considering leaving us for greener pastures
• All new project wizards can take advantage of working sets now… like PDE.
• Plug-in Spy makes its debut in this week’s I-build (select something and press ALT+SHIFT+F1)

In keeping with the “Enhancing New Plug-in Developer Experience” theme, PDE recently added new validation and a quickfix to help with access restriction issues that could be solved by exporting a package. For example, say you have two plug-ins: a and b. If a attempts to use a class from b and b doesn’t export the package containing the class, you’ll get a pretty warning and quickfix now:

The next stops on the “Enhancing New Plug-in Developer Experience” train for me are:

• 198724: Raise warning when . is not on bundle-classpath and there are source folders
• 176360: Create marker if PDE projects uses external jar
• 201347: Merge Plug-in Spy into PDE

By popular demand, I tossed Plug-in Spy on a temporary update site for people to try out and give feedback. Note, it needs Eclipse 3.3+ and to try it out, simply select things and press F9. If you have ideas, feel free to file bugs or enhancements against the PDE Incubator with the tag [spy]. I recently added the support of getting at those pesky menu ids you need to contribute to Eclipse menus (thanks Paul Webster).

Note, this is incubator code and there is no guarantee of stability or “product readiness.” Maybe given another bloody mary or two, I can add more functionality ;p

William Godwin once said,

The philosophy of the wisest man that ever existed, is mainly derived from the act of introspection.

On my last plane ride (after a bloody mary), I did some introspection about what I think Eclipse is missing the most. With Eclipse 4.0 in the not so distant future possibly, it’s a good time for introspection.

I tried to think back about 4-5 years ago when I started to first get into Eclipse development. What was the worst pain for me? Well, here’s a good one. One of my first Eclipse-related task was to extend a commercial IDE by adding some menu entries to an existing view and develop a new editor. Sounds easy? Well, at least not back then for me. I was scouring source code to find what the relevant “object contributions” would be along with looking for the source code of the Java editor as a staring ground. This ate up a lot of time for me and left me frustrated with Eclipse but I sort of grew accustomed to it as a normal way of development (plus, I got really familiar with the Eclipse plug-in base when time went on).

I thought to myself… well, now that I’m a seasoned Eclipse developer armed with another bloody mary and about 90 minutes until my flight lands… what can I hack up as a proof of concept to improve my workflow? Let me introduce Plug-in Spy:

What’s going on here? I simply selected a class within the Package Explorer and hit F9 to let Plug-in Spy introspect what’s going on with Eclipse at the moment. Plug-in Spy pops up and lets me know what the active part (along with the implementation class PackageExplorerPart and which plug-in it came from) and active selection. This may not look incredibly useful to a seasoned Eclipse veteran, but for newcomers who ask the question “Where can I see the source for this view or editor” (which by the way, is the #1 asked question at conferences for the PDE team).

I also did a thought experiment while in the plane when analyzing one of the Mylyn features (Report as Bug):

I thought… either Mik/Eugene/Rob must’ve scoured some Eclipse source code first to figure out what the proper way of adding this functionality would be. After they implemented it, they probably thought, “this shouldn’t of taken as long as it did.” If they were armed with good introspection tools, they would have seen that an object contribution of type LogEntry would do it:

What’s the lesson learned here? Eclipse lacks good tools for introspection (we have things like SWTSpy but that’s not enough) in my opinion. I think when we look toward the future of Eclipse, we should keep tools like this in mind. This would allow developers to focus more on their implementation instead of crawling through and learning Eclipse’s internals.

Note: The Plug-in Spy currently exists in the PDE Incubator and is not “product ready” nor are there plans currently to make it so at the moment. It’s simply a proof of concept for now to collect ideas and see what people think. My next step with the spy is to add support for getting information about menus. This will help with the eternal question of “oh my gosh, how do I contribute to this menu or toolbar.” If you’re interested in enhancements, please report them to bugzilla under the Incubators component with the [spy] header.