If you’re writing a non-trivial RCP app under eclipse the chances are you’re going to be using a couple of extra plugins that provide additional functionality. Probably including:

• org.eclipse.ui.editors
• org.eclipse.ui.workbench.texteditors

I mean, this makes sense, if the functionality’s already there you may as well use it, right? Allow me to introduce a little friend

These little cunts are contributions that get added by plugins, so unless you’re going to alter the Plugin they come from itself (Note to you, don’t be retarded) you need a way to hide them. For some FUCKING REASON this is made a whole lot harder than it needs to be. Especially since documentation is a little thin on the ground. First up, you need to work out which contributions are being added. ActionSets are the usual culprits. You should be able to find out which ones are enabled easily enough, so I’m not going to show you how to do it.

Once you’ve found out, In ApplicationWorkbenchWindowAdvisor.java, override the postWindowOpen() method and give it something like this…

@Override
public void postWindowOpen(){ 
  IWorkbenchPage page = PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage();
  page.hideActionSet("org.eclipse.ui.edit.text.actionSet.navigation");
  page.hideActionSet("org.eclipse.ui.edit.text.actionSet.annotationNavigation");

  ...

}

And hey presto. The actions you didn’t want and didn’t ask for in the first place are gone.

So the first application I’m working on at this new job of mine is an eclipse RCP application that will allow the users to perform a task that is currently dull, boring and scripted.

I like RCP, it’s got a good feel to it – however, there are more than a couple of problems that I’ve encountered.

• It’s a *rapidly* evolving and changing platform. Although the eclipse team don’t put out a release more than once a year, books tend to take a bit longer than that to write, print and proliferate. The only entry level textbook that seems to be kicking about is [McAffer Lemieux], which was written for eclipse platform version 3.1 – June 2005. I use 3.3…

• Related to the above. The eclipse community, whilst I’m sure very willing, suffer from developer syndrome – every FUCKING thing is, for the most part documented for people who have an understanding of the last version, or related systems. There are always tutorials kicking about, true, but these are often much simpler than is required

• No matter what they tell you, it’s hella-complicated. It’s a piece of piss to get one up and running, thanks to the really-pretty-good wizards that build the basics for you. (I’ve not met anyone so far who’s not used them to get their initial project state up and running). However, when you do something to a configuration file and it breaks everything you’re pretty much fucked, unless you’re going to spend a day fixing the problem you’ve just introduced – screaming at the eclipse newsgroups and hunting wildly for something valid for eclipse 3.3.

So here’s my plan, I’m going to document, in as simple a set of terms as I can, exactly what I’ve discovered about the configuration files required for an RCP app, probably dedicating one article to each. To kick off with I’m just going to explain what the damn things are called…

First of all, there are (basically) three categories of config files.

1. Files for the plugin(s) that provides the functionality you want the end product to have
   1. plugin.xml
   2. MANIFEST.MF
   3. *.target
   4. plugin_customization.ini
2. A file that describe the entire RCP as a product
   1. *.product
3. Files that control the building of the application
   1. eclipse based build
      1. build.properties
   2. ant / PDE build headless builds
      1. build.xml
      2. build.properties

Each one of them needs to be more or less perfect in order to get the application building, and they all depend on each other, in more or less the order listed above. I’ve intentionally left out the source files that are required to get the configuration right, since they’re mainly covered in tutorials that can be found with a little googling.

Next stop, plugin.xml. Whooo!

OK, I admit that I was too lazy to write my own fucking webpage. I accept that by using an open source package I’m going to have to make a series of design sacrifices in the name of getting shit done, but why, WHY, do all of these packages have to have their own ingrained little terminologies. Why do I have to:

1. Write my own set of webpages embedding the php elements for “article” or whatever in them. BUT, do it eight or nine times.
2. Hack someone else’s code to pieces just because at the time I downloaded a set of pages (see above) it was the least shittily presented, and the only starting point that didn’t make me want to crush kill destroy.

Fucking wack.

First step, get this motherfucker looking better. Second step, take a crowbar to the WordPress technical steering team.

Hell, I don’t know why I’m doing this. I already have a blog…

I’ve recently started a new job in software development, and while I’m a clever, clever bastard, there are many many things that you don’t seem to be able to learn except by doing. Annoyances, undocumented features that are essential and all that crap, and as I’m using industry standard tools for the first fucking time I thought I might share the experiences with the rest of the world. If anyone comes accross this piece of crap then please bear in mind it’s more of a notepad for me to remember how I did a certain thing on a certain day. K?

K.