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!

What's new in the SWT for Eclipse 3.7

A lot of Mac stuff but a few items seemed important:

• on Win7, taskbar items show Job image as overlay. We need to attach images to our Jobs even without Win7 because they appear in the Progress view. And we'll be done when we do move to Win7.
• SWT.WRAP now works for Buttons of all styles (e.g. SWT.PUSH, SWT.CHECK, SWT.RADIO).
• can now set preset of duplex when printing. We should test our dusty old Jasper will do this.
• WebKit now default browser if it's installed.
• Touches and Gestures now supported but I don't think we're there yet.

10 Techniques to Test a Plug-in

This guy was full of good ideas. He's putting together a blog that will have code samples and more details on testing:

1. MANIFEST.MF using OSGi PlatformAdmin service for basic identity values and dependencies
2. plugin.xml, e.g. parsing extension points .exsd files to determine attributes then testing extensions for valid values
3. commands and handlers using ICommandListener and IExecutionListener
4. views and editors using IWorkbench and reflection
5. a PropertyTester by parsing its extension to drive tests using IEvaluationService with various values
6. a SourceProvider, testing its variable is the same when obtained from the extension, the implementation class, and from its current state
7. expressions as used in a plugin.xml using the IEvaluationService with various contexts
8. dialogs and wizards using Display.timerExec()
9. unwanted messages using an ILogListener and replacing the default system.out stream

His blog is at http://blog.rcp-company.com/ and I will definitely be checking back with this guy.

Getting Eclipse Preferences Under Control in Teams

An exploration of free tools that aid in maintaining preferences in a team environment. Three solutions were described:

1. "Eclipse Team Etceteras" - a feature that prompts the user on startup of a new workspace to install preferences from the location specified in a fragment. Also allows when switching workspace to copy preferences in the switch. More information here.
2. "Workspace Mechanic" - a more invasive but capable feature that is task oriented and can manage preferences, java files, and plugins. File-based with HTTP function not yet released.
3. "Common Preferences" aka bug 334016 - an eclipse project than handles preferences and can optionally lock them down.

I think #2 sounds like work to maintain. I think #3's capability of locking down preferences is too heavy handed but we wouldn't need to use it and it is an eclipse project so the future is probably good. #1 sounds quite simple and probably does the job needed. I'd like to hear what the rest of the team has to say on this.

Commands in Eclipse 4: Understanding who does what

Complementary to Commands in Eclipse 3.x: the 10 most common pattern.

A description of the Command Framework in Eclipse 4.x. Much of it remains the same; the command is still an abstraction for a semantic operation, still declared as an extension as are the handlers and menus that reference it. Expressions are still used for visibleWhen, activeWhen and enabledWhen statements.

The big difference is in the handler implementation and its supporting API:

• An @Execute annotation is used on the method to be invoked.
• Optionally, an @CanExecute annotation can be used on a method called by the framework to determine enablement.
• Most objects needed by the handler are to be injected using:
  
  • @Inject (for service by interface)
  • @Named (for variables, e.g. selection)
  • @Preference (for the handler's plugin's preference store)
• An IEclipseContext is used extensively.

I missed how the IEclipseContext is to be obtained but it is core to the Eclipse 4.x Workbench model and most Eclipse 4.x development, not just the handlers. It's hierarchical and can be traversed. The handler executes in the last active context, usually a ViewPart. In the model it is a leaf under a Perspective which is under a Window which is under the Application root. The effect of this hierarchy is that a command's state, which was global in 3.x, is contextual in 4.x and can be one of many. In 3.x a command was either enabled or disabled and if there were two menu items in two separate views for a single command, e.g. print, they were both either enabled or disabled... which often made no sense. In 4.x they are separate contexts and so individual states.

It's comforting that plugin.xml extensions can probably be left as they are and that only the handlers need migration. Though the injection and context use is radically different, it is also apparent it is leaner code and that, once learned, is portable to the rest of RCP development.

Commands in Eclipse 3.x: the 10 most common patterns

A description of the different ways of using the Command Framework in Eclipse 3.x. I think our group has used them all and I believe we've done so properly. They are:

1. Simple command with a default handler and a simple menu contribution for it.
2. Providing static parameters to commands.
3. Specifying a toggle state for a command.
4. Specifying a radio state for a command.
5. A pulldown command with sub-menu items.
6. Dynamic menu contribution.
7. Using "activeMenuSelection" in an expression.
8. Adding a control to a toolbar - not sure if we've done this but I've seen it.
9. PropertyTester.
10. Calling Command Framework API, e.g. programmatic invocation.

The Java Renaissance

A announcement by an Oracle architect and an IBM engineer that IBM will be joining OpenJDK. IBM promised to bring significant bugfixes and performance improvements. Oracle stated Java is their highest priority because they have so much invested into and depending on it. They also stated they are still very much in competition with each other and that Java's future is secure.

Some details on Java 7:

• to be released end of July 2011 - developer release available now
• introduces switch on String
• the initialization of a new genericized variable need not specify the generic, e.g. Collection<Foo> c = new ArrayList<>();
• I/O simplification, e.g. ResourceStream automatically closes
• improved fork/join operations when developing for multiple core CPUs

p2, your savior or your achilles heel? Everything an Eclipse team needs to know about p2

Complementary to Discovering the p2 API's. More details on the rules of working with p2:

• do not touch the installed files on disk
• do not move or delete plugins
• do not extract into the plugins folder - a zip can be used as an install location to p2 for proper management
• do not use the dropins folder
• do not replace published content, i.e. publish a new jar under an already published version
• always use a qualifier
• use feature patches if new release not feasible
• do not remove released repositories - use retention policies instead (?)
• use categories - composite repositories can introduce a category layer
• use descriptive feature names and provide descriptions
• MetadataGenerator has been removed in Eclipse 3.7 - use Publisher instead

The Future of Hudson Continuous Integration

A brief talk to dispel rumors of Hudon's demise in lieu of Jenkins. Hudson development is still ongoing with plans of better Maven integration and a lot of refactoring. Also announced was the promise of a Tycho book due next week!

Declarative Services - Dependency Injection OSGi Style

An overview of Declarative Services, most of it already known to us but included some interesting tips. XML descriptors are loaded at application start and bundles are lazily loaded. MANIFEST.MF header Service-Component can use wildcards if XML uses version 1.1 schema but not if using 1.0. Some description of low-level API such as ComponentContext but its use is discouraged. Four types of components were identified:

• Non-service component - can interact with services but not retrieved
• Service - the usual case
• ServiceFactory - can instantiate multiple copies of a service
• ComponentFactory - used by infrastructure

An overview of component attributes was given but this is well documented.

During the Q&A section someone asked how to obtain a declared service in application code! The answer was surprisingly simple, that declared services are registered with the Eclipse ServiceRegistry so they can be retrieved the same way any Eclipse service is obtained, such as the ISelection or IHandler services. The details are a little fuzzy to me now but I believe this means, rather than using a BundleContext and/or ServiceTracker, a service should be requested by interface from one of several ServiceProviders available throughout Eclipse. I'm pretty sure the Site is the best entry point for this. I think we need to test this and replace our current efforts to get services with this more correct, less-dependency-involved method. Given the information provided in Singlesourcing for Eclipse 4.x and Eclipse 3.x though, we might want to consider creating special classes to do this workbench interaction that we can remove when we migrate to Eclipse 4.x. This solves the question left at the end of 10 signs you're doing OSGi wrong. We also should make sure we're always using the 1.1 schema.

Developer Onboarding: Getting Developers Productive in Minutes Instead of Days

A presentation of how Nexus Pro can provision an IDE. The tool can be used to email a web link to new developer that opens a JNLP that starts a p2 installation, effectively installing an IDE. The installer can go on to check out projects. A view is provided with Refresh and Update buttons that can keep developers synchronized in their tooling. Can also be used to revert an IDE to a previous state to work on a bug in an old codebase. Preferences however are not well supported. Only supported by the commercial Pro version.

10 signs you're doing OSGi wrong

Examples of bad ways of using OSGi, summed up as:

• Ignoring dynamism - assuming services are always available.
• Using OSGi as an "applications" level programming platform - using OSGi API in pojos rather than keeping them pure and separating out OSGi-dependant code.
• Ineffective modularization - OSGi has a granularity at the package level which should be adhered to; package rather than jar cohesion should be sought.
• Over/under use of services - not everything should be a service but properly used it can simplify code.
• The myth of "pure" OSGi - plan for and regularly perform refactoring. Package code such that inevitable refactoring can move the package without breaking API. Be agile.

Lots of examples of what not to do but correct usage was at the architectural level with few code examples. For instance we were told to not use BundleContext or ServiceTracker to get a service, leaving me a little dumbfounded. They did state we should use Declarative Services so we're half right. Now I'm on a mission to find out how to get a service.

Discovering the p2 API's

Some warnings about how to get into trouble with p2 and the correct way to use it. Primarily this means letting p2 handle all things related to an installation and not modifying the application by hand... ever. Described was how to tweak the Update Dialog GUI, e.g. removing the repositories selector and add button, and how the headless API has been greatly simplified. Good overview information if we needed to interact with the p2 API but no practical information on setting up or maintaining a p2 repository as I had hoped.

Next Generation Development Infrastructure: Maven, m2eclipse, Nexus and Hudson

More information from another one of the guys from Sonotype. The presentation was focused on their development issues though rather than practical information. Of interest though was that they are trying to make Tycho an Eclipse project along with Aether, the Maven dependency-resolution engine. They seem to be focusing their commercial work on Nexus Pro and Hudson Pro while Tycho and Maven/m2eclipse seem to be planned as open-source. They spoke briefly of their Maven Shell product that is open-source too. It's an enhanced command-line tool that reputedly greatly speeds up Maven commands. If we don't move to m2eclipse we definitely should check this out.

Keynote - What Is Watson?

A presentation on the search technology behind Watson, the Jeopardy winning computer. A detailed description was given of the challenges of natural language queries and some of the strategies the team implemented. Approximately one hundred person-years went into the endeavour. The team is now mainly focused on medical applications - providing comprehensive search capabilities to medical professionals. Other efforts include multilingual capabilities and the ability for Watson to respond with questions designed to increase confidence in final answers. Quite interesting but not really portable to our work.

Architecture Patterns and Code Templates for Enterprise RCP Applications

The best of the day! Some insightful lecture and 4 well-scoped hands-on practical exercises.

An architectural pattern was discussed and formed the basis of their project structure. Core to this was the notion of a "bootstrapper" - an executable product with minimum code that can be easily deployed to a client and that, when run, automatically connects to a P2 repository and installs features. Sound familiar yet?

They described a set of four project types they referred to as a "quad":

1. Bundle+
2. Packaging+
3. Deployment
4. Release engineering

The pluses denote multiple projects. The "Bundle" is self-evident. "Packaging" would be feature(s). Both are simple Maven/Tycho-built projects. The "Deployment" part is either the product project (the bootstrapper) or an update site project and the P2 repository providing the features. The "Release Engineering" part (or "releng" as they called it) is the Maven/Tycho bits - poms and modules.

An interesting take on what is becoming an industry standard way of building RCP applications. More at the presenters blog.

The labs were simple, well-scoped, solutions-provided, PDF-described, well-discussed, and zipped for us. We should be able to use the poms as examples. It'll be some time before we can use the auto-update-on-startup code but we have it now. Like I said, best of the day.

Open Source Tools in Continuous Integration Environment

The title sounded good but it was way too basic to be of much use. Described was the concept of Continuous Integration citing the use of Maven, Subversion, Hudson, and a SourceForge-like JasForge developed by the presenter. Examples were dated.

Singlesourcing for Eclipse 4.x and Eclipse 3.x

Complementary to Eclipse 4.x Compatibility Layer: What's hot? What's not?

The strategy of moving Eclipse 3.x workbench-dependant code to separate abstract classes was echoed. An example was provided in extending ViewPart with an abstract class that their view implementation then extended. The new abstract class used the 3.x workbench code while the view implementation was insulated. Later that view class can be modified more subtly in removing the extends of the abstract and adding annotations like @Inject to do the same work.

Further, the 3.x-dependant code can be moved to separate bundles, e.g. UI, 3x-int, broker-services. The latter is an abstraction of API usage also changed with 4.x: obtaining OSGi services and resource-provisioning code (image and font registries, and message bundles).

A couple concepts were mentioned without example that seem interesting but puzzling. The first was the notion of testing such a setup with all three targets: 3.x-, 3.x + compatibility layer-, and 4.x-based builds. The second was using 4.x annotations in 3.x code. I'm not sure how either would be done but they sound like they could be helpful. I can contact the presenter for more information if we need it.

Eclipse 4.x Compatibility Layer: What's hot? What's not?

A session discussing migrating Eclipse 3.x-based code to Eclipse 4.x. The 4.x org.eclipse.ui.workbench plugin can be used with a 3.x plugin, acting as a "compatibility layer", if the 3.x code makes some adjustments. Specifically these involve how it references workbench code which the 4.x development model injects via annotations when needed.

The presentation suggested one strategy that seems feasible. Though onerous, they suggest combing code to find such workbench references (registering listeners, getting active Shell, etc) and abstracting it out to a set of 3.x-dependant abstract classes that can be abandoned when switching to 4.x.

The presentation went on to describe some of the other probable problem areas:

• Presentation extension deleted (we don't use it)
• Theme extension deleted (we might be doing something with this in Properties)
• Combining ActionSets and Menus extensions can be problematic. I think ActionSets are actually deleted and we don't use them anyway. 
• He cautioned that Menus contributions may be affected in sort order, placements, etc. Something to watch out for.
• A few Eclipse implementations of setFocus and dispose had to be fixed with 4.x so they're areas to watch.
• @noextend, @noimplement and internal packages are off-limits!

Introduction to OSGi

Short session with a very polished presenter. A little history lesson on the evolution of modularity up to today's OSGi that was enlightening. Nothing much to report here, I took in this session because it was the most relevant at this time slot and there might have been something new.

Building Eclipse Plugins and RCP Applications with Tycho, Nexus and Hudson

This one promised to be interesting because of its relevance to our own work. It was a little disappointing though because I think it could have been a little better prepared. The presenters certainly knew their subject (they commit on Tycho, Maven and m2eclipse) but I think at times the message was a little unclear. About half the session was hands-on exercises which were a little buggy so people were having problems (me included). They seemed to be pushing their commercial product, Nexus Pro, a little too much for me too. They said it has P2 support but didn't go into details. I think we can do without it personally. They were using m2eclipse though which gives me hope that we still might be able to adopt it. Having to do command line programming then refresh eclipse products should be unnecessary these days.

Having discussed Tycho with Alex and Allan at work I don't think I actually saw anything new. Just the expected parent and child poms, new maven archetypes, etc. They did have a novel idea though in splitting up the module specification into a separate "aggregator" project with its own pom and situating the parent pom in its own project. They also had these projects as siblings of the code projects, using "../[project id]" when referring to them. I like that they are all sibling projects because it would mean not needing to check out a parent folder in tortoise, again keeping the developer within eclipse. I'm not sold on the aggregator but it was interesting.

A couple tidbits:

• Tycho reportedly does not support specifying versions with Export-Package (we're not doing so now).
• Tycho reportedly does not support version ranges with Import-Package (we generally just set a minimum version).
• No publishing support - local Update Site project builds and deposits files locally; need to somehow get the artifacts to the P2 repository server.
• They have SWTBot tests running with their local and Hudson builds (mvn -X) but they haven't tried WindowTester - have we picked the wrong GUI tester?
• They have FindBugs working with their Hudson builds.
• No code coverage Hudson plugin support yet. They're considering JaCoCo.

And they're off!

Registered and met up with Alastair. Looks like we both want to attend some of the same sessions but we'll see how the week plays out. I'm just going to write about the ones I attend but we might combine forces for our report when we get back. For anyone who wants to play along, all the sessions are listed here.

Singing Metallica in the Rain on YouTube

So I've been hanging out in the restaurant downstairs at the hotel drinking coffee and hoping the wind and rain would let up. I was hoping to take a train into San Francisco but it's pretty miserable out and it's supposed to continue into tomorrow. Oh well, the people watching is good.

There are two other conventions going on here now too. One is for barbershop quartets and the other is for motorcycle customization. It's not too hard to guess which people are attending: notebook computer in tow, face full of tattoos, or a bowler hat and makeup.

You want to take gate 3 sir

So I don't know where I would have ended up had the Boarding Pass Inspector not stopped me from going through gate 2... but I'm glad he did. Those who know me know I'm not a morning person and can be a little stabby without coffee. A pre-dawn flight before breakfast and apparently I wander off sometimes too. Good to know.

Anyway, a few winks on the flight to Chicago, a walk the distance of Ottawa to North Sydney to find the connector (biiig airport), a quick breakfast with coffee, and I made the correct gate for the second flight on my first approach.

Just checked into the hotel in Santa Clara. Really hungry, a little tired and probably a bit stinky. They've been polite to me so far so I think I'll clean up a little before some foraging.

I passed Wayne Beaton on the way in. He's a big eclipse guru whose numerous online articles have answered numerous questions of mine. I'll have to say hi the next time.

Oh yeah, it's raining :(

Going to California

Woohoo! Warm and sunny here I come!

I'm flying out of Ottawa tomorrow morning headed for Santa Clara California to attend EclipseCon 2011. Should be interesting.