In many RCP applications your views (ViewParts) will not be singletons. Perhaps you have a tree or project view which is probably a “show only once” view, but for others it’s more likely you have them flagged in the plugin xml to say allowMultiple="true" in the <view /> tag. For multiple views sharing the same primary ID you are probably already aware that you can (and have to) set a secondary id on them to make them unique. This secondary id will stay with the view as long as that view is open (even if you restart your application as the secondary id is saved in the Eclipse metadata and then re-set when your RCP application starts up again – assuming the view is set to be restorable).

But there’s some things that can be a bit frustrating, which is the point of writing this article. First, as your view has to be defined in the plugin.xml and [should you want to] Eclipse/RCP has currently no way of hiding views in “Show View” (see Bug 249451 for details and possible workaround to hiding views from “show view”). Any view opened with Show View won’t have a secondary id.

Second, you may want to control what that secondary id looks like, as you may want to use it as an “ID” for saving custom view-specific settings (for example, grid-specific data such as column widths, column orders etc).

Third, you want a central place where the creation of those multi-views are handled where you know that the ID set on them will be of the format you defined.

And lastly, you probably want some of them to be automatically opened in your “default” perspective with proper secondary ids. So let’s get to it and see how we can make all this work for us with the goal of us not having to think about it any more once we’ve created the necessary code.

If you’re using Eclipse RCP (or even standalone SWT with JFace) you are most likely using MenuManagers in various places, for popup menus, toolbar menus, etc. You might be happily using them without much of a thought or care of where they end up after they have been shown or how their internal workings actually “work”. Danger lies down that happy path.

You probably never paid much attention to the disposal of widgets except that “master widget” you call dispose() on (usually a shell).. and just because of this, it’s time to dig into the “why”, “what” and “no kidding” of MenuManagers as there are undoubtedly a few of the “no kidding” unless you are already fully familiar with them.

Maven is a great tool for building Java projects, there’s no doubt about that. Unfortunately there is one great feature still lacking of Maven which is important when you use third party dependencies, namely detecting when your components use dependencies of different versions without your knowledge.

What does that mean? It’s probably easier to explain by example. Imagine you have a project that has two dependencies (can be your own created jars or third party, or anything Maven-buildable really). Your first dependency uses Log4J v1.0. Your second dependency uses Log4J v1.1. When you compile this project Maven will by default use the “nearest wins” strategy, meaning it might pick Log4J v1.0 or Log4J v1.1, whichever is nearer in the transitive hull of dependencies. What you probably wanted however, was for the compilation to tell you that you have two “modules” depending on the same library, but different versions of that library. Log4J is perhaps not the best example, but imagine that the dependency in question is a mission-critical dependency, and that any version discrepancy may cause catastrophic failures that can be very hard to track down via debugging.

To solve this I wrote a Maven plugin nearly a year ago that we are now using for every Maven-built project in our company. It’s a simple plugin that does the complex task of detecting all version clashes (even deeply nested ones) and will report them back to you either as warnings or errors (or ignore them). This project was submitted to the Maven team a while back but has not been integrated as a default Maven plugin yet, so it will now become a downloadable Software Project on Hexapixel until it hopefully becomes a standard module.

This will not be a long post, but I want to point this out as it may be important. I know some are using the Ribbon Widget in their applications despite the “Alpha” state that it is in. This is of course great, but I want to make sure people are aware that Microsoft are quite proud of their Ribbon (which I think they should be), and as such, they want to know about any application that uses a “third party” Ribbon.

What does this mean for you, the user? Not a whole lot, except that Microsoft wants to know that you are using a “ribbon look-a-like” widget commercially and they want you to get a license. They have a site set up where you can license the Office UI (which includes the Ribbon), so if you must, you probably should read through it and see how it applies to you. I believe it’s free, but I haven’t taken deep look at it yet. The link to this is http://msdn.microsoft.com/en-us/office/aa973809.aspx.

And another interesting Ribbon related link is something Tom Schindl just sent me, which is a Bugzilla entry for a request to add the Ribbon API to SWT. You can find that here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=90145. I think it would be fantastic as then it would be native and not custom drawn like the current Ribbon.

*Post updated to reflect bug-fix and version update to 0.2.3. Update site should also work now*

A new version of the Java Source Helper is out. This version is almost a rewrite of the entire code as it now uses the Java AST tree for parsing code. This should make it much more “happy” with custom formatted code. The popup will also show the parent-scope history to give you an even better idea of where you are in the code.

There are quite a bunch of new features, and I tried to include all requests I’ve gotten so far (although some may not have made it in yet). In any case, the details page contains full info including new screenshots, new download links, etc. Go check it out!.