Eclipse 4's Modeled UI: less sweating over workbench APIs, more grinning over simple POJOs

A discussion of developing in Eclipse 4.x, specifically around the Workbench Model. In Eclipse 4.x, all of the visible pieces are contained in a single application covering EMF model, with the exception of Wizards and Dialogs. The model replaces IWorkbenchWindow and IWorkbenchPage. It is specified in an .xmi file as a hierarchical tree of IWorkbenchParts, each extending MApplicationElement or an abstract subclass. The application is the root with child nodes for window(s), toolbar, menubar, (optional) perspective(s), and stacks. Plugins wishing to contribute views, commands, handlers, etc would do so in a .xmi fragment which is combined with the application model at runtime. A renderer is specified with the application that dictates how each part looks. A renderer can state a view is to be shown as a collapsible "accordion" panel if desired. Renderers can be specified for entire applications or separate ones for specific parts.

A drag&drop + properties editor is provided for editing the application model. Validation prevents adding an invalid part as child to another part.

Some effects of this model structure are:

• can now detach things that previously could not be detached
• can now put things in a detached part that previously couldn't
• can now detach an editor
• can put views in editor area
• can now put editors in view stacks
• parts can reside outside perspectives - appearing fixed as perspective is changed
• less (all?) interaction with plugin.xml in lieu of .xmi fragments.

That's it. My brain is full. I'm going home :)

Concurrency in Eclipse: Best Practices and Gotchas

A brief discussion of concurrency within Eclipse, primarily through Jobs and ISchedulingRules, and a few tips for troubleshooting them:

• Avoid excessive synchronization as third-party libraries may be doing their own and you may cause race conditions, deadlocks or thread starvation. It should be a last resort, especially on the UI thread.
• Use Jobs rather than RunnableWithProgress.
• Deadlocks are usually caused by poorly written ISchedulingRules, either too vague or too restrictive.
• Enable the Show Monitor function when debugging.
• In testcases, spawn multiple threads that access the same API to find non-threadsafe API. Use ISchedulingRules on Jobs to limit access to that API.

Eclipse Runtime out-of-the-box

EclipseRT is a set of Eclipse runtimes or target platforms designed for different environments, e.g. RCP, embedded, web, cloud, etc. Many have reported it was difficult to find information on these runtimes so the EclipseRTP project was created. They provide images (such as an out-of-the-box Amazon cloud server), instructions, guidance and samples for working with the various runtimes.

Now we know what EclipseRT is :)

Birt 360 - Would Your Users Like BIRT Based Dashboards

Birt 360 is a commercial product that allows end users to create custom dashboards displaying selectable Birt reports and/or native Google Gadgets in a browser. The designer view is ajax-enabled and allows drag and drop of existing reports, or parts of reports, creation of new reports, and any Google Gadget onto a multicolumn, multirow layout - very much like a portal. Reports allow drilling up and down. Filter modules can be added allowing dynamic filtering of reports. Dashboards are secured but can be shared. A server component is included for persistence, security and administration but reportedly the Birt reports' datasources can be any valid Birt datasource, including local Java objects in an RCP were the webpage to be displayed in a view.

Graphical Editing Framework (GEF) 101

A brief overview of GEF, Zest and Draw2D. Draw2D is the SWT-equivalent layer, though not strictly native widgets. Zest is implemented like JFace, with Content- and LabelProviders that allow using a domain-specific model directly while GEF is a lower-level, more explicit and more powerful API. Zest is for display only while GEF allows editing and palette support. GEF uses a hierarchical set of Figures (boxes within boxes) and connectors (simple Anchors and fancy Routers). Figures specify EditParts for editing and Policies for functionalities like canSelect, canDrag, canEdit, etc. GEF displays its canvas in layers, one for figures and one for connectors. The canvas is then displayed in a viewport for zooming and scrolling. An overview (or thumbnail) view is provided to provide context of what part of the canvas is displayed through the viewport.

A good concise presentation that took some of the mystery out of these projects.

Functional test automation for Eclipse applications with Jubula

A GUI tester that does drag&drop! At least they claim it does. This was a tutorial session where they gave us a copy of their RCP application based on Eclipse 3.6.1 and walked us through creating and running a test case. No code involved - everything is based on a hierarchical set of semantic "modules" that you assemble and set some properties on then run. Many modules are included or you can create your own. An example is a button click. The module can take input, in this case the text on the button, as a parameter provided at runtime. All the parameters for all the modules for a test suite can be provided from a flat file - good separation of test data from test "code". You can write the test suite without the app under test though I guess you'd need at least descriptions or screenshots to know what to test. Creating a test doesn't involve code though selecting and arranging modules and setting their properties is not exactly word processing but a tester should have no problem.

It's based on GUIDancer, a commercial product, that they've open-sourced and are now developing as an Eclipse project. The free version lacks the code coverage reporting that the commercial version provides. But what's free is really impressive. SWTBot API is not intuitive. WindowTester produces buggy tests and is not open-source. Neither one does drag&drop. I want to try this.

I was wondering about running tests during build and poked around http://www.eclipse.org/jubula/ and found this:

Is it possible to run GUIdancer / Jubula in a continuous integration process?

Yes, we have a command line client which allows this. The use of this client is described in the user manual.

You can also run tests on the AUT using a virtual frame buffer if you want the testing to take place independently of the actual GUI environment.

---

Is it possible to run GUIdancer / Jubula with Ant?

There is no direct ant target for executing GUIdancer or Jubula. However, the exec command can easily be used, for example:

< exec executable="GUIdancerCMD.exe" vmlauncher="false" failonerror="false" resultproperty="testResult" />

---

Can you recommend any best practices for integrating GUIdancer / Jubula into the build environment?

We recommend using a tool or framework for continuous build integration. This tool can then execute tests and evaluate the results.

We use Hudson as our continuous build integration framework. Hudson runs on a dedicated test computer, which has a stable environment and configuration. Our tests are run from this machine, with AUT agents running both locally and on other remote test machines. Hudson:

checks out the source files from the repository,
builds the application,
starts the tests, and
reports the test results.

The most basic smoke tests are run after commits throughout the day, more complex tests are executed every night, and tests with very long execution times are executed over the weekend. In this way, defects can be identified within a short time after they are committed to the repository.

---

What ports does GUIdancer / Jubula require for testing?

We require various ports to communicate in two directions:

From the client to the AUT agent: this port is defined in the preferences.
From the AUT to the client: this port is dynamically chosen, and cannot currently be defined. Therefore, any ports available on your test machine must also be open on the machine from which the test is being run.

If opening all ports in this way is not an option, we recommend using the command line client on the test machine to run the tests, so that all communication is done locally.

Looks promising to me!