Modular Mind

In a previous post, I provided a set of projects that you could use to get a sample build running quickly. The idea was that getting your first build running is half the battle. From that point on, you can make small, incremental changes to accomplish what you like.

A common request I’ve received, though, is to provide a similar sample build that includes the running of JUnits using the Eclipse Test Framework. Well here it is! Just download and import the sample projects, and follow the directions in the included readme.txt file.

Note: If you want to run this sample build using Eclipse 3.2, you’ll need to work around a PDE Build defect. For instructions on how to do this, check out the “Problems parsing feature file in a product build” section on the PDE Build wiki page.

In response to my last post on obfuscation, Jeff McAffer asked if I had seen any space savings in the obfuscated code. Well l thought it would be an interesting exercise to run the numbers, and the results were surprising.

What follows is the list of plug-ins being obfuscated in my Market Contours application. A total of 809 classes are obfuscated in one way or another (some have exclusions that protect class and method names). The obfuscation was done with Zelix KlassMaster and line numbers were not scambled (scrambling line numbers can increase file sizes). So here are the numbers:

Plug-in							Before	After	Diff	% Diff

com.marketcontours.cache_1.0.0.200707122146.jar		5,103	5,679	576	11.29%
com.marketcontours.client_1.0.0.200707122146.jar	98,565	98,751	186	0.19%
com.marketcontours.context_1.0.0.200707122146.jar	102,159	93,646	-8,513	-8.33%
com.marketcontours.core_1.0.0.200707122146.jar		22,559	23,949	1,390	6.16%
com.marketcontours.data.text_1.0.0.200707122146.jar	18,404	20,097	1,693	9.20%
com.marketcontours.data.web_1.0.0.200707122146.jar	13,323	14,401	1,078	8.09%
com.marketcontours.data_1.0.0.200707122146.jar		26,926	28,042	1,116	4.14%
com.marketcontours.evaluation_1.0.0.200707122146.jar	176,009	180,630	4,621	2.63%
com.marketcontours.future_1.0.0.200707122146.jar	18,391	17,849	-542	-2.95%
com.marketcontours.resource_1.0.0.200707122146.jar	132,675	138,066	5,391	4.06%
com.marketcontours.result_1.0.0.200707122146.jar	28,213	27,802	-411	-1.46%
com.marketcontours.runtime_1.0.0.200707122146.jar	56,840	52,486	-4,354	-7.66%
com.marketcontours.stock_1.0.0.200707122146.jar		12,468	12,069	-399	-3.20%
com.marketcontours.ui.builder_1.0.0.200707122146.jar	98,212	95,134	-3,078	-3.13%
com.marketcontours.ui.chart_1.0.0.200707122146.jar	12,835	14,392	1,557	12.13%
com.marketcontours.ui.data.text_1.0.0.200707122146.jar	8,594	8,526	-68	-0.79%
com.marketcontours.ui.data.web_1.0.0.200707122146.jar	2,375	2,399	24	1.01%
com.marketcontours.ui.data_1.0.0.200707122146.jar	33,472	31,890	-1,582	-4.73%
com.marketcontours.ui.result_1.0.0.200707122146.jar	63,844	64,452	608	0.95%
com.marketcontours.ui.runtime_1.0.0.200707122146.jar	7,537	8,285	748	9.92%
com.marketcontours.ui.series_1.0.0.200707122146.jar	67,262	62,512	-4,750	-7.06%
com.marketcontours.ui.tradeshape_1.0.0.200707122146.jar	20,757	19,691	-1,066	-5.14%
com.marketcontours.ui_1.0.0.200707122146.jar		196,728	200,764	4,036	2.05%

Total change: 	-1,739	-0.14%

The results show that this obfuscation resulted in little if any space savings, with some jars actually increasing in size. One reason for this is that there is a good deal of inter-plugin API which causes many package names to be excluded from obfuscation. This type of API is pretty typical of RCP applications, so it’s likely that they’re generally not going to shrink much during obfuscation. And then when you add the Eclipse plug-ins and a JRE to your distribution, the small size decrease will appear even smaller.

So in short, there are good reasons for obfuscating an RCP application, but decreasing the size of your distribution isn’t one of them.

In this article I’m going to take you on a tour of the process I use to build a large-scale RCP application. Obfuscating an RCP application can seem like a big challenge, but it’s really not so bad.

Read the rest of this entry »

As Eclipse plug-in and Rich Client Platform developers, we face unique challenges in how we structure and execute our unit tests. In this article, I suggest an approach to unit testing based on Eclipse fragments that can help us overcome these challenges. If you find yourself frustrated with your current plug-in testing options, read on!

Read the rest of this entry »

I often work with teams getting started with Eclipse RCP, and the most common complaint I hear is that it’s too hard to set up automated builds. PDE Build can be frustrating to work with because it’s a black box. Your code goes in one side and a fully branded RCP application pops out the other. But if something goes wrong inside the box, where do you start to debug?

In my opinion, the best way to work with PDE Build is to get a very simple build running in your environment. Then make small, incremental additions, verifying the integrity of the process after each change. So the immediate problem for a team becomes: How do I get that first build running?

To help with this, I’ve put together a simple feature-based RCP product build. Just download and import the sample projects. If you follow the instructions in the included readme.txt file, you should have a build running fairly quickly. Before you know it, you’ll be seeing that always elusive BUILD SUCCESSFUL message flash across your screen!

Note: If you want to run this sample build using Eclipse 3.2, you’ll need to work around a PDE Build defect. For instructions on how to do this, check out the “Problems parsing feature file in a product build” section on the PDE Build wiki page.

Update – October 6, 2009: The sample projects have now been updated to work with Eclipse 3.5.1

One suggestion I always make to developers getting started with the Rich Client Platform is to set up a research workspace containing all of the Eclipse IDE plug-ins. The Eclipse IDE (along with the PDE and JDT) is the ultimate RCP application and examining this code is the best way to learn how things should be done.

Are you developing a forms-based editor? Check out the PDE UI plug-ins to see how the Manifest Editor is constructed. Would you like to create a preference page with an unusual UI layout? Look through the many Eclipse IDE preference pages to find something similar. Then go look at the code.

I almost always have my research workspace open as I’m developing applications. It’s like having an RCP code encyclopedia! Follow these steps to create one:

Read the rest of this entry »

There are many parts of RCP that are a little rough around the edges. That’s to be expected in an open-source framework, and to be honest it’s one of the things I like about RCP. Sure, commercial frameworks are cleaner and packaged more “professionally”, but they have to give up a lot of functionality and dynamism to achieve this.

But once in a while I hit a problem that just makes me go ugh! (and grrrr!). One of the best examples of this is the fact that if you don’t give an editor an icon, your editor won’t show up. If you happen to have logging turned on (and if your launch configuration does not include the -consoleLog parameter, it really should), you’ll at least get a somewhat informative message on startup:

!ENTRY org.eclipse.ui 4 4 2007-04-30 15:37:05.037
!MESSAGE Plugin com.marketcontours.ui.builder, extension org.eclipse.ui.editors
Required attribute 'icon' not defined

But you may not understand the true importance of this message until you try to open your editor. At that point you’ll more than likely get a very unhelpful NullPointerException, as the editor registry will simply return you a null editor.

I probably shouldn’t admit this (being a trainer and all), but I’ve actually had this happen to me repeatedly, and for some reason it always takes me a while to figure out what’s going on. It may have something to do with my failing to believe that omitting an icon could have this kind of effect. Also, in every class I teach, there is at least one student that hits this problem and is completely dumbfounded. I’m going to assume based on this random sample that many beginning RCP developers run into this.

There is already a Bugzilla entry for this defect (it’s actually listed as an enhancement), if you feel like voting for it.

The Commons Navigator Framework is one of the more complex parts of the Eclipse API. It can be difficult to get started with the framework, and one of the hardest parts is simply getting a basic navigator to appear with custom content. This tutorial is designed to get you to that point so that you can start exploring the framework on your own.

There are quite a few steps, but it’s not as bad as it looks. So let’s get started!

Read the rest of this entry »

The Common Navigator Framework was introduced in Eclipse 3.2 to provide navigators with pluggable content, filters, sorting and much else. It’s a powerful new feature, but for some reason it wasn’t made to work with the RCP. In my opinion. every significant addition to the Eclipse API should be made RCP compatible unless it’s really IDE specific. RCP compatibility shouldn’t just be an afterthought, it should be a core design principle. Ok, I’ll get off my soapbox now.

RCP developers have gone through a lot of pain trying to get the CNF to work, and most of these attempts involve trying to fake out the mechanism that discovers a navigator’s root node. The approach I’ve taken is a bit simpler – just extend it. The core of the CNF is the CommonNavigator class, which is meant to be used as is. My approach is to extend this class and override the getInitialInput method, which is responsible for root node discovery. I’ve done this on a number of projects, and the rest of the CNF works as expected.

Hopefully someday I’ll be able to use the CNF as intended, but this is a small price to pay for now.