Modular Mind

I’ve just spent some time updating my example showing how to set up PDE Build and the Eclipse Testing Framework. I’ve generally cleaned things up and I’m now creating the test environment in the correct way.

As a special bonus, I’ve also thrown in coverage analysis using EMMA. And before people ask, yes I have tried to use Clover with PDE Build, but have had little luck due to Clover’s dependence on a specialized Java complier. If anyone has gotten this to work, I’d love to hear about it.

And finally, I had to change this example to use a test plug-in instead of a test fragment. For some reason when running Eclipse 3.4 (maybe related to p2?), the ETF is not finding tests in fragments. If anyone has any ideas here as well, please let me know.

You can download the new example here.

NOTE: I’ve discovered that the EMMA instrumentation task fails if you’re running the script inside of Eclipse and you have spaces in your workspace path. Avoid spaces in your path and you should be good to go.

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

Eclipse provides great tools for testing RCP and OSGi applications using JUnit, but there a few areas that are problematic.

• It’s not easy to run all the tests in a set of plug-ins. The test launcher allows you to run all the tests in a single project, but RCP and OSGi developers are usually working with a large set of test plug-ins. Sure it’s possible to create test suites, but keeping suites up-to-date is a real pain.
• It’s not easy to use test fragments. To find out why you’d want to use test fragments instead of test plug-ins, check out my previous post on Testing Plug-ins with Fragments. The problem is that even the standard suite-based solution does not work with fragments. There are workarounds, but they’re not very pretty.
• It’s not easy to run all of your tests during an automated build using the Eclipse Testing Framework. This is related to the first point above, and again you can use suites to handle this. 

You can then run the test suite both inside of the Eclipse IDE and using the Eclipse Testing Framework. I should note that this works only for JUnit 3.x tests. JUnit 4 describes suites using annotations which makes it (as far as I can tell) impossible to dynamically generate a suite at runtime. If anyone has a solution to this, I’d love to hear it. 

As always, comments and fixes are much appreciated.

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 »

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