RCP plenary

Nick Edgar and Jeff McAffer are presenting. They’re relating RCP releaeses to popular TV shows.

Eclipse 2.1 RCP – Monster Garage – this was hacks by pioneers who stripped down the Eclipse SDK to create a platform for building non-IDE apps.

Nick: This is similar to how Monster Garage gutted a PT Cruiser and stuffed a wood chipper inside.

I saw someone who did this at least year’s EclipseCon and it looked pretty good. However, they had to do a lot of things to get it work and they had to create custom builds of Eclipse to get to what they wanted.

Eclipse 3.0 RCP – What Not To Wear – my wife loves this show and apparently Nick’s does as well. They took the SDK hacks and remade it so that you can get RCP out of the box.

Eclipse 3.1 RCP – The Amazing Race – Not quite sure what to make of that reference, but 3.1 is where I believe that RCP will come of age.

RCP is middleware. I’d say it is more like an App Container, like there is a Servlet Container or an EJB Container. But the same principle applies: it lets you write the stuff that matters, not the plumbing.

RCP apps look native. Yes. The user doesn’t really want to be confronted that your app is built on Java. They want it to behave like the other apps that they use.

RCP helps academics do things that aren’t IDE related, like control instruments.

IBM uses RCP for its Workplace Client, which is reminiscent of Outlook.

NASA uses RCP for its Maestro – Space Mission Management app.

There’s Eclipse Trader, which lets you track stocks.

There’s also eRCP for embedded devices.

OK… there’s a good start. I’m hoping to see a lot more. Only problem… how can you tell? I guess you’d have to dig into the directory structure and see if you can find a plugins directory. If you were just looking at the UI, it would be harder to tell.

“Aggressive laziness” – this is a great phrase. Basically extreme lazy loading. Don’t load code until you really really need it. This helps Eclipse perform well even with lots and lots of plug-ins.

What people like about RCP: You can focus on the 20% of the app that is domain-specific rather than the 80% that is common infrastructure.

What people don’t like about RCP: Learning curve of the APIs. I’d say instead that learning the APIs is an investment. For example, you could argue that going to a university is hard. That’s true. But it is an investment in knowledge that you can reuse over and over again in your life. The same goes with RCP and other Eclipse APIs.

Also there are some challenges with security support, but hopefully some folks will step forward and help with this.

Also there are some problems with apps that expect class loading to work in a certain way. The Eclipse team is working to address this in 3.1. Great.

Base RCP = OSGi + Runtime + SWT + JFace + Workbench. This is about 5-6MB currently and they are looking into slimming this down even more.

Optional RCP = Help, Update Manager, Text, forms, Welcome Page / Intro, Cheat Sheets, GEF, EMF. And you can use any other plug-in really. I blogged earlier how you could grab the database connection wizard from WTP and use it in an RCP app.

3.1 adds a lot of tool support for RCP, which I think is a big enabler for the RCP community. There’s product tooling available now, along with RCP templates. Bundle tooling will come later in M6.

“The friendly blue screen” LOL That’s what the Eclipse team is calling the Eclipse welcome screen.

RCP Application vs RCP Product – Application is like any standalone Java app. Product has a product ID, a product Name, a launcher name (executable), a root directory, a spalsh screen, icons, a custom About dialog. Currently you need to update the build.properties file to tell it where the icons are. You can then export the product, which builds all the plug-ins and outputs it to a zip, which you can then unzip and run via the launcherName.exe (on Windows.) I’ll have to report back later to see if RCP Product creates a proper .app on Mac OS X.

You can deploy your features and thus your RCP via Java WebStart. The only thing is you have to handcraft a top-level JNLP file, which hopefully will be done by 3.1. The underlying JNLP files are created for you. This is done via Export Deployable Features. This is pretty cool. They did this with the entire Eclipse SDK(!)

There is system tray integration. Not sure if this is SWT, JFace, or RCP. I wonder if there’s OS X menu item integration…

I have to give a hand to the RCP guys. Their demos were very smooth. One of the demos was to show a chat client talking to an RCP-based chat client called “Hyerbola”. They showed off the system tray, update manager, dynamic menu adding, and integration with Swing (which was for an XMPP debugger).

Future: RCP started as a grass-roots effort and the team wants to continue to engage the community. RCP Tooling will continue to increase (great), making it easier to create and maintain RCP apps. There will be some more flexible layouts (for perspectives I think).

RCP call to action: Participate in the community. Think about building a platform around your industry. Post your application to the eclipse.org / community / rcp page, which I guess is like an RCP Sightings page.

“Eclipse is not just for tools anymore!”

One Reply to “RCP plenary”

Comments are closed.