Macs, Modularity and More

RCP Best practices panel (Live transcript)

Since's Ed's chairing the Eclipse RCP talk, I'll do a blog-by-blog account of it :-)

Ed Burnette (SAS)

Boris Pruessmann (Adobe Systems)

Robi Khan (Cognos Inc)

Jim Adams (SAS)

Jens Nahm (DaimlerChrysler TSS)

Sandi Schoelhammer (American Power Conversion)

Ed: What did you do to determine whether to use RCP or not?

Jim: SAS wanted to use the same UI across all applications, and internal groups didn't create a shared reusable internal applciations. By using the Eclipse RCP, there was buy-in from all teams. NetBeans was also considered at the time but during the 2.1/3.0 timeline, NetBeans didn't have the traction that Eclipse did.

Sandi: Developers investiated into a week using a variety of tools. Eclipse RCP+GEF was used to provide a full scale demo in a week. Eclipse RCP and NetBeans RCP and Spring RCP were considered, but Spring was alpha so was discontinued pretty quickly. Because there was some native requirements (e.g. ActiveX) Eclipse RCP won

Ed: Audience;; who's in the 'just thinking about Eclipse' and 'already decided on Eclipse' categories?

Audience: Eclipse looks boxy when it's started.

Jim: You can use the presentation manager...

Audience: but it's not easy to do that ... (bit of a debate about specific problem not related to RCP)

Audience: Can you please repeat the questions?

Ed: Ok, so the question was, can you please repeat the question ... (laughs)

Audience: Have you tried the Trolltech Qt in Eclipse RCP?

Robi: No, but there's a few differences between the Qt and SWT in terms of look and feel. Cognos evaluated various toolkits; AJAX, .Net or Eclipse SWT/RCP in the end went with SWT/RCP

Audience: Is it worth $50,000 for Qt developers license when SWT/RCP is free.

Audience: What about automated user testing?

Robi: Any windows testing tool will work on SWT on Windows widgets (buttons, lists etc.) -- but won't work on custom components. If you have an accessible interface, then UI testing hooks into that can work well since the UI tests don't get so fragile and tied to the presentation. Not having automated UI tests is just as bad as having automated UI tests that break every build.

Ed: can you suggest any tools?

Jim: Abbot can work with SWT for automated testing.

Sandi: We use mercury to test, but it's a bit expensive.

Jim: We tried to use that, but it wouldn't work with Swing.

Audience: We should push for TPTP to record Eclipse RCP tests and to script the UIs.

Audience: We wanted to use abbot, but had problems; you keep havign to use handles. If you have a helper library and AspectJ to determine whether Eclipse was ready to receive a click, and that way removes the need for waiting or doing testing.

Audience: What process are you using to build RCP applications?

Robi: We're using PDE build to do our work, and it hooksinto the version control.

Jim: We use Ant because we build a lot of things. We don't build much in the way of RCP.

Boris: We're using CruisControl with PDE build, and because we weren't using CVS (using perforce) we had to do some kind of hacks to make it work.

Audience: Any recommendation on any teamwork processes?

Sandi: We're located in 5 different countries and use Subversion to get our code around.

JIm: The collaboration in the IDE isn't quite there yet. The Jazz BoF was phenomenal

Audience: How do you decied how to split up code into how many plugins?

Sandi: We try to make the plugins as lego-like as possible. We try to do applications that are just plugins, specific to certain applications. The core plugins are always separated.

Jens: We don't use plugins; we just have two plugins. Our current needs don't cry for many components.

Jim: I encourage to split the plugins up. You can use extension points to allow plugins to use it

Robi: Some plugins are split up on locations. But there's plugin benefits, access controls and packaging that's used. Also, with plugins you can partition your public classes and document plugins better. If you have a bunch of code and you have found you had to make packages public, then use bundles instead and use friends. Don't obsess about it. Don't worry about whether it's a plugin or not; if your code is good, you can refactor later.

Audience: Do you use import package or require bundle for your packages?

Boris: We're using Require-Bundle, but moving to the Import-Package, because it seems to be more flexible for when you want to change certain components.

Jim: We're using Require-Bundle, but we've not considered it.

Audidence: Do you use obfuscation or licensing to the bundles?

Jim: We don't do any obfuscation, because most of the stuff is server-side, and all you need to check is the license.

Robi: We use weigard to do the obfuscation.

Ed: Is it worth using obfuscation to reduce the size of the code, by reducing the size of methods?

Sandi: We use that; if you're deploying to a thin client, size is important.

Jim: We use a key to allow plugins to start. If the key is invalid, the plugins don't start and the functionality is disabled.

Sandi: We use WebStart to deploy, and instead of using a license key, we dynamically generate the JNLP from the user credentials in the dataabase.

Audience: Do we use plugins that work in an IDE or plugins?

Audience: We use that, and it's OK if you make sure your dependencies are well defined.

Jim: Good point. How do you deploy an RCP, and how do you prevent other plugins from being installed into an RCP? We're trying to make sure that A, B, C and D all use the same jar, there should only be one copy on that jar. The same is also true of the RCP applications. The goal is that there should only be one set of plugins for the core, and other RCP apps should be able to separate out functionality.

Sandi: Using WebStart, we don't have that problem. It caches the jars.

Audience: If the URL is the same between RCPs, then it will cache them.

Sandi: The WebStartMain manages it for you.

Audience: Has anyone taken a Swing/NetBeans app, and ported it to SWT? If so, what are the challenges?

Sandi: We've done that. You need to learn SWT and setup which threads are going to call updates to the SWT. Other than threads, it's not that bad. If there's a significant amount of Swing code and have Swing experience, it takes time for them to get used to the new toolkit and way of doing things.

Jim: We have many Swing applications and some SWT apps, and we need to use them. For example, how do I handle repaints() so that they don't look nasty, or tab traversal into and out of the SWT app. Since it's an embedded frame, it can have some issues and it needs to be worthwhile.

Sandi: You can do it, but guard against deadlocks. But it's possible.

Audience: What about Mac OS X when you do that? It doesn't work?

Boris: There's some work on that, but not for 3.2

Audience: So what OSs are you targetting?

Jim: We mostly focus on Windows, maybe Linux. We don't have any Mac OS X, so we don't have too much of a problem.

Sandi: We do some fancy drag-and-drop, so we are only focussed on Windows.

Ed: I'd like to talk about deployment. How are you getting the apps on the machines?

Robi: We've got a team looking at it. WebStart would be good, but there's issues. You can't assume that the JRE is the one that you want to run on. Also, you may not want to replace an old one on a machine if there may be breakages. So we ship our RCPs with a JRE in the subdirectory. We also want to launch an app from a webstart; but we can use it as a stub launcher to use an RCP installed on the local system. (I.e. not running WebStart directly but using WebStart to run a program to System.exec() the RCP on the local filing system.) I hope that the issues with startup.jar and eclipse launcher get fixed in the future.

Jim: Tivoli provides some management of applications, so we need to use that for some customers. We have to follow the customer's needs; but that means we can't rely on update sites.

Sandi: WebStart uses Pack200, which canbe used to reduce your RCP downloads to about 25%.