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.