Layout Image
  • Home
  • Training
  • Eclipse RCP Best Practices
  • About
  • Contact

Archive for Builds

Updated PDE Build and Test Example

by Patrick
August 4th, 2008

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

DZoneLinkedInDeliciousDiggEvernoteFacebookFriendFeedGoogle BookmarksRedditSquidooStumbleUponTechnorati FavoritesTwitterYahoo BookmarksShare/Save
Categories Builds, Rich Client Platform, Testing, Tips
Comments (69)

Running Unit Tests for RCP and OSGi Applications

by Patrick
June 12th, 2008

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. 
So to sum things up, I want to run sets of tests across multiple plug-ins or fragments and I don’t want to use suites. My solutions has been to create a simple bundle test collection plug-in that harvests unit tests based on a set of filters. To use the plug-in, you need to do the following:
  1. Download the bundle test collector which is licensed under the standard EPL. The archive contains the test collector plug-in and also an example plug-in showing proper usage.
  2. Add the com.rcpquickstart.bundletestcollector plug-in to your workspace.
  3. Create a plug-in that will contain a suite or set of suites that will load tests based on filters. The tests making up the suites will be generated dynamically, so you won’t need to maintain them. This plug-in will need to depend on the com.rcpquickstart.bundletestcollector and junit plug-ins, but that’s it.
  4. In your suite, add the following method:
    	public static Test suite() {
    		BundleTestCollector testCollector = new BundleTestCollector();
    
    		TestSuite suite = new TestSuite("All Tests");
    
    		/*
    		 * assemble as many collections as you like based on bundle, package and
    		 * classname filters
    		 */
    		testCollector.collectTests(suite, "com.mycompany.", "com.mycompany.mypackage.",
    				"*Test");
    
    		return suite;
    
    	}

 

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.

DZoneLinkedInDeliciousDiggEvernoteFacebookFriendFeedGoogle BookmarksRedditSquidooStumbleUponTechnorati FavoritesTwitterYahoo BookmarksShare/Save
Categories Builds, Rich Client Platform, Testing, Tips
Comments (47)

Running Automated Tests with PDE Build

by Patrick
August 6th, 2007

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.

DZoneLinkedInDeliciousDiggEvernoteFacebookFriendFeedGoogle BookmarksRedditSquidooStumbleUponTechnorati FavoritesTwitterYahoo BookmarksShare/Save
Categories Builds, Rich Client Platform, Testing
Comments (68)

RCP Obfuscation and File Sizes

by Patrick
July 13th, 2007

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:

1
Plug-in                            Before    After    Diff    % Diff

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
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.

DZoneLinkedInDeliciousDiggEvernoteFacebookFriendFeedGoogle BookmarksRedditSquidooStumbleUponTechnorati FavoritesTwitterYahoo BookmarksShare/Save
Categories Builds, Rich Client Platform
Comments (0)

Obfuscating an RCP Application

by Patrick
June 22nd, 2007

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 More→

DZoneLinkedInDeliciousDiggEvernoteFacebookFriendFeedGoogle BookmarksRedditSquidooStumbleUponTechnorati FavoritesTwitterYahoo BookmarksShare/Save
Categories Builds, Configuration, Rich Client Platform, Tips
Comments (32)

Getting started with PDE Build

by Patrick
June 6th, 2007

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!

Eclipse 3.5 Sample
Eclipse 3.6 Sample

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.

DZoneLinkedInDeliciousDiggEvernoteFacebookFriendFeedGoogle BookmarksRedditSquidooStumbleUponTechnorati FavoritesTwitterYahoo BookmarksShare/Save
Categories Builds, Configuration, Rich Client Platform, Tutorial
Comments (362)

Want to know more about RCP training?

Get information on private training options, pricing, availability and references.

Email address

About me

Patrick Paulin

Patrick Paulin is a software developer and trainer specializing in modular technologies such as OSGi and the Eclipse Rich Client Platform.

Patrick lives in Madison, Wisconsin with his wife and two daughters.

Email - patrick at modumind dot com

Looking for training in Europe?

My European partner vogella offers expert Android and Eclipse training, consulting and development support.


Modular Mind
Copyright © 2013 All Rights Reserved
iThemes Builder by iThemes
Powered by WordPress