Chris Aniszczyk's (zx) diatribe

The PDE family is growing! One of PDE’s beloved committers, Brian Bauman, is a brand new father! Say Hi to Trent!

I tend to joke around with Wassim that PDE has certain things that only one person (hi Jeff) in the world uses. A good example of that is Target Definitions which people only come across accidentally when trying to create a Product Configuration. Why is it that only “one” person in the world uses Target Definitions? Is it a doc problem? Maybe, but it’s my opinion that feature adoption always comes down to evangelism via proper channels. However, that’s another discussion, back to Target Definitions 😉

In simplest terms, Target Definitions allow you to manage your target platform in ways you didn’t think was possible before. For example, you may be developing a product or component that only needs a specific set of plug-ins or features. As an example, let’s say you were a handsome developer working on the new Equinox provisioning effort. As a new Equinox provisioning developer, you know that you don’t need the whole SDK checked in your target platform so you used to manually check plug-ins that you didn’t want included. That kind of sucks…. as a smart Equinox provisioning developer you decided to create a target definition that would represent the target you are developing against (provisioning).

Once you do that, it’s easy to craft your target platform the way you want and also share that target platform with your fellow provisioning developers (since target definitions are contained in a shareable .target file).

That’s Target Definitions in a nutshell. I tend to use Target Definitions frequently when working with products that serve as platforms and I’m working with a component that exists on top of a product. So now that you know about them, go use them and file some bugs (or enhancements).

Wassim and I from PDE will be at Eclipse Forum India (EFI) next week giving conference attendees a full-day of PDE love 🙂

If anyone at the conference wants to sit down with us and chat about PDE/Eclipse (over an optional frosty beverage of course) please let us know. At the last EclipseCon, the PDE team heard good ideas (particularly from those demanding Band XI guys ;p) that we incorporated into the 3.3 release of PDE. We would love to do the same at EFI (for 3.4).

On a side note, as a committer representative, I would love to hear what issues or suggestions Eclipse committers in the area have. At Eclipse Forum Europe, I heard some complaints which I acted on and would like to do the same at EFI. Feel free to drop me a line and we can chat.

In the PDE team, we had this running joke that every Eclipse-related debate eventually degenerates into talking about the SWT_AWT bridge (this was true two EclipseCons ago, now every debate ends up talking about Provisioning/Update). Well, to make those SWT_AWT guys happy (especially on the Mac), we made a small change (fix) to how Eclipse applications are launched in PDE. In the past, we used to implicitly pass certain arguments (os,ws,arch,nl) to the framework, this is no longer true. In 3.3RC1, you’ll notice these arguments located in the program arguments box (explicitly).

We fought this change for awhile because in my eyes, it slightly complicates the launching user interface, but it was necessary to keep everyone happy. PDE will automatically migrate your old launch configurations (using some clever Debug APIs) so there’s no worry 🙂

I’m currently stuck in the DFW airport which is like being in prison for owners of laptops that need a battery charge. The amount of power outlets (near where you can get a beer or some food) for personal use in the international terminal can be counted on one hand. I feel like I could make a million dollars with some extension cords and a powerstrip.

On the bright side, one of the trickiest PDE bugs has just been closed. It dealt with case sensitivity issues in the manifest editor. The framework doesn’t care whether your header is Bundle-ClassPath or Bundle-Classpath, and PDE should be flexible enough to handle these cases 🙂

Furthemore, developers can now use the enhanced JFace Text WordRule to deal with case sensitivity issues in their own editors.

In the next I-build, you’ll see that PDE‘s Plug-in Dependencies view has been upgraded (thank you Brian Bauman).

Oh my, it’s now easy to see how things are wired by that crazy framework!

Furthermore, it’s now possible to get a state of the [PDE] state. For example, if you had a bundle that wasn’t happy (In Eclipse Update terminology), you would see something like this:

Enjoy!

The Eclipse 3.3 release cycle has gone really well for the PDE team. Considering the relatively small size of the team, we’ve managed to fix a ton of bugs and add a plethora of new enhancements (from people who didn’t submit patches btw ;p). The PDE motto has always been, “We do tooling but our business is people.” With that stated, the PDE team is entering the polish phase of the release cycle and we implemented things known as “theme weeks.”

This week’s theme is “anything product related” needs to be polished. Next week is primarily all things cheat-sheets. We are inviting the community to comment and file new bugs that they would like solved before 3.3 closes. We will pay special attention to these requests and try to fit them in the plan as we understand that PDE plays an important in the future growth of Eclipse.