… for make benefit glorious nation of PDE!
Ok, I had a long weekend 🙂 I recently added sexy filtered tree support for PDE’s hidden gem known as the Plug-in Registry (see picture below). Hope everyone enjoys it! The performance of the filtered tree has improved quite a bit lately, however, the challenge associated with these filtered trees is where it makes sense to put them without cluttering the user interface.
After having a few busy weeks working on getting Lotus Expeditor (the platform that Hannover another others are built on top of) out the door (I miss you PDE, I’ll be back), I will finally be hosting Austin’s edition of the Eclipse birthday party. It will be at North by Northwest (an awesome brewery in North Austin), so come join us for free drinks and celebrate Eclipse’s 5th (there will be margaritas to compliment the beer in the true Austin fashion).
The next milestone of Eclipse 3.3 will have one of the coolest features ever (in regards to UA)… Help Content Providers allow Eclipse to read help content in any format. This was one of the dreams I had for Eclipse when Lawrence Mandel and I were writing the Authoring with Eclipse article.
The problem here was that a lot of products ship documentation that’s based on either DocBook or DITA (two popular documentation formats). To get these formats to work with the Eclipse help system, transforms were written to generate Eclipse help system compatible artifacts (ie., toc.xml). Hopefully with the new Help Content Providers yet to be written, this no longer will have to be necessary. This will also allow people to use standard documentation formats instead of kludging a bunch of HTML files together. Furthermore, this should spur more adoption of DITA and DocBook.
Thank you UA team.
Ever have one of those days when freakn’ nothing works and you wish to do things like in the picture below?
I filed a bug tonight against the foundation infrastructure (hi Denis) to support something like OpenGrok for searching Eclipse source code quickly (how many times have you wondered who the heck is using that magical id?). What are people’s thoughts on this? Good idea? Bad idea? Denis too busy for this and needs to be bribed by booze?
Update:
Seems koders.com already supports this type of search. Thanks for the tip David.
In the Eclipse 3.3 plan, there’s an item about product customization. It seems work has been well under way by our dear pirate lovin’ Kim Horne. I personally have some mixed feelings about product customization (but Kim is behind it so good things will come!), maybe I’m an idealist, but Eclipse’s motto has always been to add and not take away (or transform in this case). Product customization may have merit in some cases, but I think it takes away from the spirit of building on top of something great and refining it in the process to make it more consumable by everyone. Is XSLT kludge the right solution here?
However, I do have a case where product customization could possibly be useful… in PDE we have a bug open to refactor the templates in PDE into a separate plug-in. In theory, you could use product customization to modify PDE’s plugin.xml to remove all templates so only your product’s templates would be included. But is this right? Isn’t the solution for PDE to have a separate plug-in for templates so products could easily drop the bundle if they don’t want the extra templates? I’m worried about cases like this where people go for the kludge instead of pushing for the proper refinement.
Other than that, I think Kim is exploring an interesting area 🙂
After feeling like one of those people in the Lost TV series that disappears from the island… (was tracing some file handle leak problem from hell) I finished up an article regarding using and extending the OSGi console in Eclipse. For those who don’t know, launching Eclipse with the -console parameter can be a ton of fun (you can start and stop things and take down Eclipse in no time!). If you type help in the console, you’ll notice a ton of commands available. Ever wonder how to have your own command (can be useful in debugging situations regarding your specific service)? Well, wonder no more, here’s a simple example from the upcoming article (the important parts are implementing CommandProvider and prefixing commands as methods that start with the ‘_’ character):
public class Activator
implements BundleActivator, CommandProvider {
private BundleContext context;
public void start(BundleContext context) throws Exception {
this.context = context;
Hashtable properties = new Hashtable();
context.registerService(CommandProvider.class.getName(),
this, properties);
}
public String getHelp() {
StringBuffer buffer = new StringBuffer();
buffer.append("\tuname - framework information\n");
return buffer.toString();
}
public void stop(BundleContext context) throws Exception {}
public void _uname(CommandInterpreter ci) throws Exception {
String vendor =
context.getProperty(Constants.FRAMEWORK_VENDOR);
String version =
context.getProperty(Constants.FRAMEWORK_VERSION);
String osName =
context.getProperty(Constants.FRAMEWORK_OS_NAME);
String osVersion =
context.getProperty(Constants.FRAMEWORK_OS_VERSION);
System.out.println("\n " + vendor + " "
+ version + " (" + osName + " "
+ osVersion + ")");
}
The end result should look something like this:
It looks like the OSGi Alliance and Eclipse have teamed up to showcase a OSGi Developers Conference along side EclipseCon 2007. Peter Kriens has blogged about this with details for all that are interested. It’s good to see some synergy between the Eclipse and OSGi community.
At IBM, I have some crazy product responsibilities at times. There was a case where a product had a gargantuan update site. If your update site lacked digests, Eclipse’s update core would go and fetch feature information from each feature. On a slow connection (or even on a decent connection) this can take awhile (minutes…). For the Callisto release, Eclipse came up with a solution to this problem using site digests (along with crazy Pack200). So, I decided to be a hero and create a full site digest. Oh the horror, it turns out SiteOptimizer has some problems with features that aren’t fully filled out (description, label, etc…) and also with properly parsing NL. I’m not sure how widely SiteOptimizer is used outside of Callisto, but I decided to toss a patch out on bugzilla in case someone else runs into this problem in the future.
On the verge of finishing one of my EclipseCon 2007 submissions (go submit you bums, there is hardly anything submitted), I noticed the eRCP draft plan for 1.1 has been posted. If people want to comment or propose some items, the eRCP team would appreciate it. What’s great about Eclipse is that you actually have a voice in things like this.
I personally would like to see the QTe port more developed and a GTK port started (When I think about it, my CrackBerry would like to run Eclipse). Furthermore, some Motorola involvement wouldn’t be too bad either.