Renaming Eclipse RCP – Update

It’s been two months since my post requesting that we rename Eclipse RCP, and I thought it was time to provide a progress update. The response has been overwhelmingly positive. Check out the comments on the original post as well as the discussion associated with the Bugzilla entry, and you’ll see what I mean.

So where are we right now?

First, there is a consensus that the renaming should apply only to the new version based on e4. Past versions and also future 3.x releases will continue to be referred to as Eclipse RCP.

It has also been expressed that the name should be chosen as quickly as possible so that it can be used for early milestone releases. I would prefer to see a name selected in the next month or two.

What next?

Do you have ideas for a name? An initial set of names has been captured on a wiki page, but it would be great if we had some more ideas. I know it’s the middle of summer, but that can bring out the creativity in some people! When you’re lying on the beach, why not spend a few minutes thinking about this. Who knows what you might come up with!

I’m particularly interested in names that reflect the fact that RCP brings modularity to the user interface. If you think of anything, you can either add it to the wiki directly, comment on the Bugzilla entry, or comment on this post. I’ll make sure that all suggestions make it into the final list.

In a few weeks, I’ll put together an online poll that will hopefully result in a short list of names (please do not tell Stephen Colbert). I’m sure other factors will be considered as well (trademarks, etc), but the poll will be an important part of the final selection.

I can’t wait to see what we come up with!

Logging RCP applications with Pax Logging

Adding logging to an RCP application has always been painful. Developers have struggled with the best way to incorporate Log4J and other logging APIs, and in particular with how to make configuration files accessible. Some have chosen to use buddy classloading, others have utilized fragments containing the config files.

Pax Logging to the rescue

I’m happy to say that RCP developers now have another choice – Pax Logging. There are a few great things about this library:

• Installation is easy. I’ll describe this in a bit.
• Configuration files can be placed in regular folders, either inside of an application bundle or anywhere on a users machine.
• Many logging APIs are supported, including Log4J, Commons Logging, JDK Logging, SLF4J and more. This means that legacy and third-party code can run as-is no matter what logging API they use.

Logging configuration with Pax ConfMan

Because Pax Logging requires the OSGi Configuration Admin service to work, your first step is to install this service in the form of Pax ConfMan. In my last blog post I provided detailed instructions on how to do this.

Adding configuration settings

The good news is that once you install Pax ConfMan, you’re almost done! Pax ConfMan requires the Pax Logging bundles in order to work, so we only have a few minor steps left.

The first is to add a logging configuration file. When using the OSGi Configuration Admin service, services are identified using a persistent identifier, or PID. Developers can choose the PIDs for their own services, and an implementation of the Config Admin uses these PIDs to inject properties into services.

Pax ConfMan does this by requiring that a properties file be named based on the PID of the service it is going to configure. For example, the Pax Logging PID is org.ops4j.pax.logging and so the properties file for this service will be called org.ops4j.pax.logging.properties.

If you created the folder structure suggested in the Pax ConfMan setup, simply create a file called org.ops4j.pax.logging.properties in the confadmin/services directory. You can now place whatever logging configuration you like into this file. For instance, here’s what I have for my simple test project:

log4j.rootLogger=DEBUG, A1

log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n

log4j.logger.com.rcpquickstart.logtest=DEBUG


Forcing Pax Logging to start

Just as we did with Pax ConfMan, its necessary to force Pax Logging to start up when our application is launched. To do this, we simply need add the org.ops4j.pax.logging.pax-logging-service bundle to the Configuration page of the Product Configuration Editor and set it’s Auto-Start property to true. If you’ve followed the instructions for installing Pax ConfMan, your complete list should look like this:

Fire it up

That’s all there is to it. Start up your RCP application and you should see log messages appear in your console.

Happy logging!

Configuring RCP applications with Pax ConfMan

Most applications require configuration settings. Applications are often deployed in multiple environments (dev, test, prod, etc) and these environments often require different runtime configurations. Also, it’s useful to be able to update an application configuration without a restart. If you find yourself with requirements like these for your Eclipse RCP application, you should really check out the OSGi Configuration Admin service.

Specifically, the Configuration Admin service allows you to:

• Configure the OSGi services that you provide as part of your application.
• Configure OSGi services that others provide. An example of this is the ability to configure the Pax Logging service, which I’ll explore in a second post.
• Configure Spring beans when using Spring DM. Here is a good reference for using Config Admin with Spring DM.

If you’d like to learn more about the Configuration Admin service, check out this post or the OSGi Compendium specification. In this post I’m going to describe how to set up the Configuration Admin service in an RCP application using Pax ConfMan.

What is Pax ConfMan?

The Configuration Admin service doesn’t specify any particular way of storing and accessing properties. Each implementation can do what it likes, and Pax ConfMan has opted for the simplest approach – properties files.

Setting up the target platform

The first step in getting Pax ConfMan working in your RCP application is to add the required bundles to your target platform. Here is the complete list of bundles which need to be added:

• org.eclipse.equinox.cm (download)
• org.eclipse.osgi.services (download)
• org.ops4j.pax.confman.pax-confman-propsloader (download)
• org.ops4j.pax.logging.pax-logging-api (download)
• org.ops4j.pax.logging.pax-logging-service (download)

Also make sure to add these bundles to your product configuration and run configuration so they will be included in builds and at runtime.

Forcing Pax ConfMan to start

If you run your RCP application at this point and examine the running bundles in an OSGi console, you’ll notice that the bundles added above are not started. To make the service available at runtime, we need to force them to start using the Configuration page (new in Galileo) of the Product Configuration Editor.

This page allows us to specify that specific bundles should be automatically started when the application is launched. Note that adding bundles to this page currently wipes out necessary RCP bundle settings. After adding these back in, your config page should look like this:

Now if you run your RCP application, you should see Pax ConfMan logging output to your console. These logs will tell you that the configuration folder cannot be found. So on to the next step!

Adding a configuration folder

Pax ConfMan allows you to configure your OSGi application using standard Java properties files, so we need to create a directory to hold these files. To get started, create a folder called confadmin in one of plug-ins that is part of your RCP application. You can call this folder anything you like, and the ConfMan default is configurations. I think confadmin is a better name in that it distinguishes it from the configuration folder used by the OSGi framework.

Inside the confadmin folder, create two sub-folders called services and factories. These folder names are required.

Finally, you need to tell Pax ConfMan where your folder is located, and this is done using a Java system property called bundles.configuration.location.

When running inside the Eclipse IDE, the simplest way to do this is to add an argument to your run configuration. Mine looks like this:

Now when you run the application you should see ConfMan messages indicating that your configuration folder has been located. Of course we haven’t added any properties files yet, but the wiring is all in place.

How to handle deployment

There are a variety of ways to handle configuration files in a deployed RCP application:

• Place your configuration files in a separate bundle and deploy that bundle as a folder instead of a jar file.
• Add your configuration folder to the install directory by utilizing the root property in the build.properties file for a feature.
• Use an installer script to copy the configuration files into another directory on a users machine.

No matter which option you choose, you’ll need to provide a bundles.configuration.location VM argument that points to the configuration directory.

What’s next?

Well you can now start to configure your own OSGi services using Pax ConfMan. In my next post I’ll show how to use ConfMan to configure Pax Logging in an RCP application.

Making OSGi easier

While there are a ton of benefits to be gained from adopting OSGi, it’s not a trivial task to migrate your existing code. Class loader issues can bite you and perhaps the biggest pain-point is the migration of third-party libraries.

Third-party libraries are a problem because while bundle repositories are growing in size, there are still a lot of JARs out there not packaged as OSGi bundles.

So what can we do to make it easier to adopt OSGi?

The Knoplerfish answer

Well it turns out that the Knoplerfish OSGi framework has solutions to many of these issues. Among the features offered are:

• Automatic runtime generation of manifests for non-bundle JARs
• Automatic patching of code that uses inappropriate (for OSGi anyway) class loading mechanisms
• Ability to execute static main methods inside of the framework

These solutions are covered in detail in this presentation given last year.

Why are these solutions not more popular?

I’m wondering why these types of solutions are not discussed and suggested more. Are there similar features in Equinox and Felix that I’m not aware of? And if not, are there any plans to implement them?

I’d love to hear from others whether features like these would be useful to you or not. I’d also be interested to hear what else could be done to make OSGi adoption easier. In my opinion, the difficulty of migrating applications to OSGi is one of the main things holding it back. What can we do to fix this?

Let’s rename Eclipse RCP

I love Eclipse RCP. I’ve devoted the last 6 years of my life to developing with RCP as well as teaching it to others. In my opinion it’s one of the most important (and underused) technologies for developing UI applications. Having said all that, the name is horrible and it’s time to change it.

My preference would be to rename Eclipse RCP as part of the Eclipse 4.0 release. There are few times in the life of a project when it changes enough to merit a new name, and for Eclipse RCP this will be one of those times. The work being done as part of the e4 project represents a significant evolution of the platform and will make it useful to a far larger audience. A new name (and branding) will go a long way to encourage the adoption of this technology.

If this approach was taken, we would have a year to select a new name and marketing approach. This post is a bit long, but here is where I would start.

RCP is the user interface of OSGi

The adoption curve for OSGi is turning up and developers are quickly coming to see the benefits of modular architectures. Eclipse RCP is perfectly placed to serve as the UI layer for modular software. The name and branding for RCP should reflect this focus on modularity and on its close relationship to OSGi.

I’ve seen a number of projects switch from RCP to Flex because the decision-makers thought they were choosing between two UI toolkits. They were really deciding between a UI toolkit (Flex) and a modular application framework (RCP). This is a problem.

RCP is moving beyond rich clients

When Eclipse 4.0 is released RCP will be much more than a tool for creating rich client applications. RCP and RAP are converging and there should be common naming scheme that unites them. One approach would be to have a base name for the technology that takes a modifier for each targeted architecture, something like “X Web” and “X RC”.

To use “Eclipse” in the name or not

This is a general issue with Eclipse projects. There is always a tension when a set of projects evolves around a spectacularly successful product. On the one hand, it can be beneficial to leverage the success of that product to promote other projects. But it can also lead to a great deal of confusion, and this is particularly true with Eclipse RCP.

To make this work well requires a rigorous approach to project naming and marketing so that the benefits of name recognition are not overwhelmed by a lack of clarity. In my opinion, the best example of this is the job done by the Apache Foundation. While the Apache HTTP server still exists, the word Apache has been successfully rebranded to apply to a whole host of projects. Each of those projects is uniformly named Apache X and benefits from this association.

The Eclipse Foundation has, unfortunately, not done as good a job. Eclipse is still, well, Eclipse. Most developers assume that other Eclipse Foundation projects are somehow related to the IDE and therefore unapplicable to their use cases. Individual projects are named in a wide variety of ways, sometimes using the Eclipse name (Eclipse RCP), sometimes not (BIRT), and sometimes using it as part of an acronym (EMF). Taken as a whole, the project names in the Eclipse ecosystem are extremely confusing.

On a side note (and I’m sure this is a minority opinion), I think that the umbrella names for the release train (Europa, Galileo, etc.) reinforce the idea that Eclipse (and all of it’s projects) are about the IDE.

In any case, to successfully use the Eclipse name the following two things would need to occur:

1. The adoption of a common naming scheme “Eclipse X” for all projects.
2. The application of this scheme to Eclipse itself (e.g. Eclipse Workbench)

Without this approach, my opinion is that using the Eclipse name in association with a rebranded RCP is not a good option. My vote would be for a stand-alone name.

Getting started

So much work and thought is going into e4 and there is enormous potential here. Let’s give this technology the name and branding that it needs to reach a wide audience.

I’ve purposely shied away from suggesting names here, but I’ve cross-posted to a Bugzilla entry where potential names can be discussed.

Note: If you agree with this post, please consider commenting on the Bugzilla entry (even a “+1” would help).

Why is OSGi important?

I’ve seen a number of blog posts and tweets lately asking some version of the question Why is OSGi important? If you’re one of the many people looking around at the increasing usage of OSGi and wondering whether it matters to you, here’s my answer.

I’m going to start by making a pretty audacious claim, which is that OSGi is one of the most important technologies to have arisen in the last 20 years. This does not mean, however, that OSGi is a revolutionary technology. In fact, OSGi is so important because it represents the logical next step in the long-term evolution of software development.

Where we’re coming from

To understand what I mean, let’s go back 20 to 30 years to the time when object oriented languages first became popular. One of the main reasons we adopted OO at that time was because it allowed us to hide many of the implementation details of our code.

Moving from procedural languages to OO languages allowed us to develop classes exposing a contract defined by a set of public methods.

The result was that much of our code was invisible outside of its class, and this had profound implications for the way we develop software. By accepting the apparent restriction of visibility we gained immense freedom. We gained the freedom to reuse classes without knowing their implementation details. We gained the freedom to refactor our code without worrying about the consumers of a class.

Can you imagine what a pain it would be if you had to develop software without information hiding?

Where we’re headed

Now imagine what it would be like if you could hide not only the methods within a class but entire sets of classes within a JAR. Imagine that JARs could define public contracts the same way classes do, and that these contracts would be enforced both during development and at runtime. Imagine that we could achieve all of the benefits of information hiding (managing complexity, code reuse, testability, refactoring, etc.) at an entirely new level.

OSGi makes this possible by offering up the standard Java package as a new unit of information hiding. When our code is running inside of an OSGi framework, each package in a JAR can be either exposed or hidden from consumers of that JAR.

Just as a class has a small set of public methods representing its contract with consumers, a modularized JAR (a bundle in OSGi terms) has a small set of exported packages representing its public contract. The bulk of our code lives in internal packages hidden from other JARs.

Imagine being able to rename classes, split or combine classes, move classes from one package to another, move entire packages from one JAR to another, all without having to worry about impacting the consumers of a JAR. So many of these types of refactorings are skipped now out of fear. Package level information hiding gives us the confidence we need to perform these refactorings, allowing us to react with agility to the changing needs of our users.

Modularity is inevitable

Whether OSGi in particular succeeds or not, JAR level information hiding is inevitable. The benefits are simply too great to ignore, and in 5 or 10 years we’ll all be wondering how we could have possibly lived without it.

Currently, OSGi is the only tool we have to accomplish this. Luckily for us it’s a well though-out, well tested, standards-based solution. I can’t think of one reason (besides perhaps its name) to develop an alternative to OSGi. It’s here. It works. Let’s use it.

It’s time for OSGi

Steve McConnell has a great quote that really gets at the heart of what OSGi is trying to achieve.

In Code Complete, he writes:

Software development has advanced in large part by increasing the granularity of the aggregations that we have to work with.

Because this granularity of aggregation is so critical, the move from unmodular to modular practices is as important as the move from procedural to object-oriented practices. For 20 years we’ve been limited to using the class as our unit of abstraction. As successful as that has been, it’s time to move on to modules. Its time for OSGi.

Announcement: OSGi online training now available

After only 10 years it seems that OSGi’s time has finally arrived. Everywhere you look, new OSGi-based products are being announced. Of course the Eclipse platform has been based on OSGi for some time and the SpringSource DM Server has been available for a while. But now ServiceMix 4 is taking OSGi into the ESB space and JBoss OSGi has just gone into beta. It’s great that so many more Java developers are going to be able to benefit from OSGi and modular software development.

To support developers getting started with OSGi, I’m happy to announce a new training course called OSGi Quickstart. This is a 2-day course that focuses on what you really need to know to get started with this technology . Instead of taking a grand tour of the OSGi specification, the course attempts to answer the following questions:

• What is OSGi and why is it important?
• How do I set up tooling to develop, test and build OSGi applications?
• How do I migrate existing applications to OSGi?
• What best practices should I be following for OSGi development?

The goal of this course is to give developers, architects and project managers the knowledge they need to be immediately productive with OSGi.

OSGi Quickstart will be offered publicly online. The first course is scheduled for June 11th-12th, and registration is now open. And as usual private courses are available onsite or online.

Thoughts on Eclipse RCP Training

At EclipseCon I had the opportunity to sit down with Wayne Beaton and record a podcast on Eclipse RCP training. It’s really not a sales pitch kind of thing, more of a discussion of the challenges faced by developers new to RCP.

But after we finished recording, it occurred to me that I’ve never really expressed what I feel the value of Eclipse RCP training is. It’s common for developers to approach me and say “I know I need RCP training, but how do I justify this to my manager?” Well for those of you in this situation, here is what I would say.

Time is money

The first argument is a purely financial one. It’s just a fact that acquiring knowledge takes time and effort. If you spend days or weeks at your desk assembling information on RCP from websites, articles and books, then your salary during this time is the cost of knowledge. The question is, how does this approach compare with learning from an instructor?

According to many of my students, learning RCP in a classroom is much more effective. There are a variety of reasons for this, which I’ll get to in a minute. But it seems to be true for most people that training significantly shortens the RCP learning curve. I’ve taught many classes over the past few years, and based on student feedback I’d say that RCP training often pays for itself in weeks, not months.

RCP is hard to learn

One of the main reasons RCP training is so effective is that the subject area is complicated. Unlike other technologies, RCP is not standards-based, so there is no canonical spec you can go to for answers. To be honest, RCP is less a coherent framework than an aggregation of related technologies (SWT, JFace, OSGi, Eclipse Platform).

The problem for someone learning RCP is where to start and how to acquire knowledge in a coherent and orderly way. What RCP training does (if it’s done well) is to cut through the noise and present a clear vision of what RCP is and how to use it.

Getting a team up to speed

Oftentimes RCP is introduced to a team by a self-taught lead developer who evangelizes the technology. When the decision is made to use RCP, the lead developer is often called upon to share his knowledge with the rest of the team.

The problem is that most developers are not (and do not want to be) teachers. Creating carefully designed presentations and labs is difficult. Communicating the information clearly to students with a variety of backgrounds and learning styles is even more difficult.

The real magic to being a good teacher is to remember what it was like to not know something. This might sound like a zen koan, but it’s really just another way of describing empathy. If you find a good trainer, I think you’ll be impressed by what this magic can accomplish.

Why can’t I just read a book?

This is a really good question. It’s obviously true that some people can learn RCP by reading books. That’s how I learned. But a better question is could you learn more effectively through a training course?

I’d argue that a training courses is more effective than books for a number of reason. First, students have a variety of learning styles. Some learn by hearing, some by seeing, some by doing, most from a combination of all of these. Only a training course can communicate information in all of these ways. Second, a multi-day training course appears to function something like immersion-learning for a foreign language. While people usually read books a bit at a time, there is a distinct advantage to focusing all or your mental energy on a subject for 3-4 days straight.

Speaking empirically, I’ve had more than a few students tell me that they’ve read books but that things didn’t click until they took the course. Whatever this click is, it appears to be what students need to get started working productively with RCP.

Making sense of e4

There was so much going on at EclipseCon last week that I have to admit my head is still spinning. I’m trying to get back to work, but my mind keeps turning to the people I met and the sessions I attended.

One area I really wanted to get into at EclipseCon was e4, which is the project that is attempting to redefine the Eclipse platform. The work being done is varied and fascinating, and I’ve been trying to figure out what it all means at a high-level. Well from what I’ve learned so far, the two main focuses of e4 are flexibility and simplicity.

Flexibility

The platform is becoming more flexible in so many ways, it would be hard to list them all. But here are a few examples:

• Internal structure of workbench window is up to you. Use perspectives or not. Embed parts in other parts, etc.
• Much stronger styling support using style sheets.
• Ability to create widgets and parts using different toolkits and even different languages.

One thing is clear – e4 is going to drastically increase our options when developing RCP applications.

Simplicity

The platform is becoming simpler in that the platform framework is being broken down into smaller and more uniform APIs that are loosely coupled to each other. Examples of this are:

• Increased focus on POJOs throughout the various APIs.
• Decoupling of APIs through contexts and dependency injection.

I really do think that it will be easier to develop RCP applications after these changes are made. Hopefully it will make my job as an RCP trainer easier too!

The conflict between flexibility and simplicity

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

Sir Charles Anthony Richard Hoare

What’s interesting is that flexibility and simplicity are usually in conflict. In framework design, we usually trade flexibility for simplicity and vice-versa. So how will the e4 team pull this off?

The answer lies in the idea of insightful simplicity. There are many types of simplicity, and some are not at all useful to software developers. But insightful simplicity arises when a team has lived with and understands a domain so thoroughly that they start to see the problem space in an entirely new way. Insightful simplicity can result in architectures that are not only simpler but that dramatically increase flexibility, enabling developers to create entirely new types of applications.

Insightful simplicity usually arises only after an initial framework has been created and evolved for an extended period of time. Frameworks tend to expand and get more complex as new use cases are incorporated, but eventually there comes a point when a team starts to see how the entire thing can be collapsed and simplified. This is where we’re at with the Eclipse platform, and the e4 team is now taking this insight and turning it into a reality.

Personally, I can’t wait to see what going to happen when developers get a hold of this technology. It’s going to be amazing!

Real World RCP at EclipseCon

In my opinion, one of the best ways to learn about a technology is to listen to people talk about their own projects. Developers who have been in the trenches and worked through the nitty-gritty day-to-day issues have so much to teach us and can save us a lot of time and effort.

If you agree, I hope you’ll consider attending the Real World RCP session at this year’s EclipseCon. If you do attend, you’ll hear 4 developers talk about some extremely interesting RCP usage scenarios, including earthquake damage simulation and nuclear plant testing. You’ll also hear about how RCP can be combined with a variety of other technologies, including CNF, EMF, and GEF to solve real-world problems.

So stop by Wednesday morning! If you’re currently working with RCP or evaluating it for a future project, I think this session will be worth your time.