Features vs. Product Files: A Case Study

Diamond Light Source’s synchrotron features many beamlines. A beamline is an experimental station where beams of light are used for a wide variety of scientific applications. Each beamline is controlled via client software from the beamline control room. The software is produced by the Generic Data Acquisition (GDA) team, and is called GDA Client. The GDA Client historically was written as a Swing GUI Java Application. In 2008, the GDA group began transitioning GDA to the Eclipse platform to take advantage of the many benefits Eclipse has to offer, such as:

  • moving from a monolithic implementation to well partitioned bundles,
  • better software reuse,
  • easier integration of third-party components and tools and
  • use of the many features already written into Eclipse, such as editors, views, and a consistent extensible menu structure.

One of the goals for improving GDA by migrating it to Eclipse was to streamline and improve the deployment procedure for the Client. The requirements for this were:

  • Build both interactively within the Eclipse IDE and from the command line
  • Incorporate the non-Java files like python scripts and configuration files
  • Support the individual configurations of each beamline

A number of alternative solutions were considered for solving this problem. Following general Eclipse recommendations, they all centred on using a combination of features and product files.

Eclipse features are a type of project providing a description to deploy and distribute an entire set of plug-ins that work together. A feature allows you to define what plug-ins make up the set, describe the dependencies and the versions of those dependencies. Features are used by Eclipse when creating update sites for use by the update manager. They are generally the top level item deployed if your deployment is expected to be added to an already installed instance of Eclipse.

Eclipse product xml files are the main definition of an install for a customized eclipse deployment. The product definition contains a list of plug-ins or features that make up the deployment. The product also defines the splash screen and other branding items, platform specific launch options, and which eclipse defined application to start with. An Eclipse product is used if the deployment is the entire application, eg a standalone RCP application.

Prior to complete product definition using the .product xml file, features would be used to build one or more sets of plug-ins, and something outside of eclipse, such as an ant build script, would assemble all the features, their corresponding plug-ins, an eclipse.exe – possibly renamed – and other necessary parts of an eclipse installation.

With the product xml file, it is possible to create a full deployment in one step using either the Export wizard in eclipse, or at the command line with the available ant tasks. It is possible to create an entire branded deployment in one step.

Defining a deployment using a product is a big step forward making it much easier to configure and deploy. However, there are still some drawbacks that make it more difficult to use that it could be.

One of them is that a product file can only list a set of features or a set of plug-ins, not a combination of the two. If most of your project is defined as features, any plug-ins not in a feature already will need to be trivially wrapped by a feature to be included in a product. The alternative is to list all the plug-ins in the product and not take advantage of the already defined features, leading to duplicated effort and maintaining multiple copies of the same information. Another problem is the only way to tell a plug-in to unpack on installation is to define that attribute in a feature.

For Diamond’s GDA Client, the main requirements mean that using product files are the correct option; however, features are still used due to the drawbacks mentioned above. In the GDA environment, each beamline requires its own customized deployment. Therefore, each beamline requires its own .product file. Since a feature is always needed due to the drawbacks listed, each beamline has its own feature project with its feature.xml. The feature.xml contains the list of plug-ins needed for this beamline, either as a list or plug-ins, included features or a combination of the two. For simplicity the product file is stored in the feature project so that all the beamline specific build and configuration files are located in the same location.

In conclusion products are a big step forward as a method for deploying eclipse products. However for this particular instance, they would need a couple of bugs fixed to be the ideal solution.

Debugging Embedded is Hard! – NMI Event

‘Debugging embedded is hard!’ was the sentiment behind the National Microelectronics Institute (NMI) event held at the ARM UK offices in Cambridge on the 24th of June 2008. The event was well attended, including representatives from Lauterbach, Mentor Graphics and Infineon.

The day featured a variety of presentations, all centred around the particular difficulties arising while debugging embedded systems, such as general lack of visibility and the real-time nature of the systems. The highlight of the presentations was the one given by Simon Davidmann of Imperas (and I’m not just saying that because I used to work for him). He gave an overview of Imperas’ Open Virtual Platforms (OVP). OVP presents an interesting solution to the problem of debugging by moving the issues into simulation space, therefore removing a lot of the restrictions normal embedded debugging suffers from. Couple that with the ability to deal with heterogeneous, multi-core systems and it will certainly be very interesting to see how the market responds to such technology, and how it adapts to fit the needs of system developers out there.

Otherwise, there were also commercial pitches from ARM and Lauterbach, each demonstrating their ‘latest and greatest’. With the ARM RealView demo, it was great to see it used Eclipse under the hood – your basic Eclipse + CDT install, with additional custom ARM functionality for things like profiling and trace functionality. Another endorsement of how CDT is really becoming the de facto standard for embedded C development. An unexpected bonus for me at the event was running into Mikhail Khodjaiants – one of the CDT developers working on the debug interface that I’d dealt a lot with before, but had never met face-to-face. It was nice to learn that he now actually works just down the road from me.

Welcome To The Kichwa Coders Blog

Like Alexander Fleming discovering penicillin, my first encounter with Eclipse was unplanned but fortunate. With a background in electronics, I was more comfortable with assembler than Java. However, that was the year the custom processor project I had been working on at Altera was cancelled. The only other interesting role going in the group was looking into a relatively unknown open-source project called Eclipse to see if it would be suitable for putting together a development environment for the Nios processor. I decided to give it a go. The rest is worthy of a whole separate article or two. But in short, I was soon taken with the clean architecture and potential of Eclipse for creating tools in an industry notorious for its hardware achievements far outshining the software tools.

After Altera, I had opportunities to keep working with Eclipse and the CDT, and I still continued to be in awe of how much was being achieved by the open source projects, and how much they were changing the commercial landscapes for embedded companies everywhere. In September 2007, I started up Kichwa Coders – the idea was to keep focussing on the areas I enjoy working on most – Eclipse and embedded systems. This blog presents an in-depth look into the industry from my perspective. Hope you enjoy it and let me know what you think!