Packaging the Project
After the build compiles all of the source code in the workspace with Buckminster, it executes a Buckminster target to package the result. When building an Eclipse feature using Buckminster, one would ordinarily package the result into a P2 repository using the automatically generated "site.p2" target. In this case, however, I need the plug-ins packaged as a product with a launcher. So I have created a different target in a cspex file (Listing Three).
Listing Three: The cspex file.
<cspecExtension xmlns:com="http://www.eclipse.org/buckminster/Common-1.0" xmlns="http://www.eclipse.org/buckminster/CSpec-1.0"> <actions> ... <public name="create.product.test" actor="ant"> <actorProperties> <property key="buildFile" value="product.ant" /> <property key="targets" value="create.product" /> </actorProperties> <properties> <property key="profile" value="Profile" /> <property key="iu" value="com.asolutions.lightning.test_product" /> </properties> <prerequisites alias="repository"> <attribute name="site.p2" /> </prerequisites> <products alias="destination" base="../../"> <path path="test-product/" /> </products> </public> ... </actions> </cspecExtension>
The cspex file allows me to add custom targets to the built-in targets provided by Buckminster. The new target calls site.p2 and then installs the product into the file system. In this case, the build installs the test product with the command
create.product.test. (This command actually runs the embedded version of Ant that comes with Buckminster to perform the work.)
Running the Tests
After the test product is installed in the file system, the build needs to run the tests. The Eclipse Test Framework includes an Ant file for this, but since it is a little limited, I have replaced that functionality with a custom Ant file. Because the test framework is launched as an Eclipse application and can run only a single test or test suite at a time, a test suite called "AllTests" has to be included for each plug-in fragment.
The test target in Ant launches the test framework from within the test product. It takes the name of the plug-in that contains the tests, and then saves the resulting JUnit test reports. Ant then invokes the SWTBot framework, which runs user-interface tests and saves the resulting reports. These test reports can be displayed by the Eclipse IDE. Assuming all tests pass, Ant packages the final product and the build is complete.
An automated build is one of the key units in any professional development effort. With it, developers can have confidence in the product. As a bonus, it allows the use of a continuous integration server (such as Jenkins) to keep the team on track. With the advances made in Eclipse 3.6 and the Lightning template project, an automated build for Eclipse RCP is finally within the reach of the whole community.
Micah Hainline is a software engineer at Asynchrony Solutions Inc. He works on mobile applications, Web technologies, rich client applications, and enterprise architecture.