Modular Mind

One of the things I love about being a trainer is that I get to visit and work with so many development teams. Every group of developers has their own chemistry, culture, skills and domain interests. Sometimes I think I’m learning as much as the teams I’m training.

As it happens, one of the teams I’ve enjoyed working with the most is looking for a full-time RCP/OSGi project lead. The company, EXTOL, is a small, successful ISV that creates B2B integration tools. I don’t do this too often, but I wanted to pass this on because I think it’s such a cool opportunity. What’s so cool about it, you ask?

• First, I don’t think there’s any better programming job than working for a small ISV. You can have a big impact and what you do matters. A lot.
• EXTOL is re-architecting it’s products from the ground up (this is greenfield development) and they’re using a lot of interesting technologies – RCP, OSGi, EMF, GMF and more.
• One of the coolest things they’re doing is leveraging OSGi on both the client-side and server-side. Very few projects are leveraging OSGi in this way, and I think the opportunities here are awesome.
• Finally, the team is great. The developers are smart and easy to work with, management knows how to let developers be successful.

So what’s the catch? Well, whether there’s a catch or not depends on what you’re looking for in your life at the moment. EXTOL is located in a small town (Pottsville) in the hills of eastern Pennsylvania. It’s a beautiful area with lots to do outdoors, a great place to raise a family and much more. It’s not for everyone, but I imagine it would be great for more than a few of the developers I’ve met.

If you’re interested, here’s a post on the EXTOL blog that goes into more detail. They’ll also have developers at EclipseCon, so feel free to introduce yourself to one of them (or me) if you’re there as well.

One of the talks I give most often is called “Why Java Modularity Matters”. This is my attempt to explain how modularity in general and OSGi in particular represent the next logical step in the evolution of software development. I’m actually giving this talk at the Madison Java Users Group tomorrow night, and if you’re in the area please feel free to stop by.

Anyway, I spent some time last week moving the presentation over to Prezi, which I’ve been interested in trying for a while. What I like about Prezi is that it allows you to convey structure and meaning in ways that are impossible with regular slideware.

If you’re interested in what this looks like, check out the presentation embedded below. It’s obviously not meant to convey a lot of information on it’s own, but you’ll get the general idea. And as always, I’d be interested to hear what you think.

I believe the next few years are going to be an extremely exciting and productive time for the Eclipse ecosystem. I say this not only because I’m an optimist at heart, but also because there are large scale forces pushing things in this direction.

The modular convergence

The way I see it, some of the large pieces of the software puzzle are converging on a single way of seeing the world. The reason for this convergence is the increasingly obvious benefits of modular software development. So what’s converging?

• OSGi is at the heart of this this process. It’s the glue that holds everything else together.
• Eclipse, meaning the entire ecosystem and not simply the IDE, has obviously been using OSGi for quite a while, but this usage is becoming increasingly explicit.
• Maven has become increasingly focused on OSGi due to obvious synergies in versioning, dependency management and provisioning. I think it’s fair to say that OSGi is going to be a core part of Maven going forward.
• Spring has also made a big bet on OSGi, starting with Spring DM and Spring dm Server. Spring also uses the Eclipse IDE as the basis for it’s development tools and Maven as it’s build solution.

As these technologies continue to become more interrelated, the benefits of using them together is going to increase dramatically. I don’t think it’s too far-fetched to say that these technologies will coalesce to form something like a new new LAMP-style stack for Java development.

What does this mean for Eclipse developers?

It’s in the interest of the Eclipse community to promote this convergence in any way it can. As developers, we should be looking for ways to speed up the process and also take advantage of the resulting synergies. Specifically:

• Eclipse should embrace OSGi as explicitly as possible, in many ways this is already happening. We’re seeing more and more OSGi standard services shipping with Eclipse runtimes and also increasing usage of OSGi services, particularly in the work being done by the e4 team. Another good example of the renaming of the Plug-in Development Environment to the Bundle Development Environment. These changes are a good start, but let’s see how far we can push this.
• When it comes to Maven, the story is unfortunately different. Builds are causing a lot of pain for Eclipse developers, and the quickly multiplying build tools (PDE Build, Buckminster, Athena, B3) are causing some confusion. My questions is: if Maven and Eclipse are both converging based on a shared interest in OSGi, why not focus on Maven as the solution to our build problems?
• Spring is a technology that is not commonly used in Eclipse projects, but it’s focus on OSGi-based modularity would make it a perfect fit. This would also be true for those consuming Eclipse projects, such as Rich Client Platform developers. There’s actually not a lot of technical work to do here, just some evangelization. Spring and the various Eclipse projects have a lot to offer each other, and we should start to take more advantage of this.

Speeding it up

In my opinion, the decision to make OSGi the foundation of the Eclipse ecosystem was one of the best decisions the Eclipse team has ever made. This decision has made it possible for Eclipse to participate in the convergence now taking place, but there’s more work to do. The actions we take now can slow the process down or speed it up. I say we take every opportunity to integrate with those who share an interest in modularity and OSGi. We’ll all be better off for it in the end.

I just spent some time updating the sample projects I provide to help Eclipse RCP developers get started with PDE Build. One of the main reasons for the update was to decouple the product configurations from specific feature versions, and I thought it was worth a post to talk about this.

What’s the problem?

By default, product configurations are hard-wired to specific feature versions. And if you decide to upgrade to a new version of the org.eclipse.rcp feature, for example, then your product configuration will break. You won’t be able to create valid run configurations based on your product and your builds will fail as well.

Luckily, we now get feedback in the Product Configuration Editor informing us that something is amiss.

So what can we do about this? Well one approach is to re-wire your product to the new version of the feature. You can do this by deleting and re-adding the feature, or you can also click the Properties button and modify the feature version manually. But this is a brittle approach, as you need to remember to update your configuration every time a feature version changes.

A better way

It’s now possible to decouple products from feature versions by replacing the feature version numbers with 0.0.0. In the future, a blank feature version will also be interpreted as 0.0.0 but as of Eclipse 3.5.1 the number must be added.

Also, there is a currently a defect in the Product Configuration Editor that results in a feature version entry of 0.0.0 being ignored. Of course, this won’t matter once blank versions are interpreted correctly, but for now it’s a problem. The solution is to open the product configuration file in a text or XML editor and change it manually.

The good news is that you only need to do this once. Your product will now accept the feature versions you supply in your target platform without complaint. Of course if you want to maintain the wiring between products and feature versions, by all means do that. But it’s nice to know we can decouple these pieces if we wish.

Of all the posts I’ve written on this blog, those on the Common Navigator Framework have been among the most popular. This is a little surprising to me, as I don’t hear CNF mentioned very frequently. My guess is that this framework is quietly becoming an essential part of Eclipse RCP.

Because of this, I’ve decided to write a set of posts discussing some of the CNF tips that I’ve found valuable over the years. And I think the best place to start is knowing when to use it. The Common Navigator Framework is complicated because it is trying to solve a complicated problem. It will only make your life easier if you’re using it for the purpose it’s designed for. So what is that purpose?

Modularity and extensibility

Well first, CNF was not created to make the development of navigators easier. If you have fairly normal navigator requirements in your application, CNF is probably not for you and you’ll save yourself a lot of headaches by omitting it.

Instead, CNF is designed to create navigators that support modularity and extensibility. With CNF, various OSGi bundles in your RCP application can contribute navigator content at runtime.

CNF allows your bundles to declaratively contribute content to a navigator, and this is not a simple exercise. As users of CNF, we need to wire together navigators and their content in sophisticated parent/child relationships, and then overlay on top of this structure a set of actions, filters, drag/drop handlers, etc.

Does it have to be so hard?

Some of you might be thinking modularity is supposed to help us to simplify our applications. Why does this stuff have to be so darned hard? Well this is true to a point. Modularity allows us to take information hiding to an entirely new level and to the extent that we can hide complexity, our applications become simpler.

But when dealing with modular UIs in particular, the difficultly arises when we work with the joints or pivot-points between modules. In these specific cases, there is always complexity because we have to define in detail how our modules relate to each other.

So the next time you’re struggling with a complex CNF extension point, ask yourself whether you really need this functionality. If you do, then embrace CNF for what it is: a complex solution to a complex problem.

What would I like for Christmas? Thanks for asking! Well, besides a Mac mini, what I’d really like is a simple update manager for Eclipse RCP applications.

Up to now, we’ve had two options for updating our applications: wiring in the Update Manager or coding something from scratch. The problem is that the Update Manager is overkill for most RCP apps and the API is fairly complicated.

What I would like to have is an alternative to the Update Manager that provides very basic update functionality. Call it Update Manager Lite, if you like. For those of you running OS X, what I’m thinking of is something like the Sparkle framework that many Mac applications use.

Would this be of use to anyone else? I’ve opened a Bugzilla entry suggesting this and comments would be appreciated.

Update: There’s already a Bugzilla entry for this feature, so the above entry has been marked as a dup. Please direct any comments you have to the original Bugzilla entry. Thanks to Susan McCourt for pointing me in the right direction!

Many people attend technical training classes each year, learning everything from Microsoft Word to the latest, greatest programming language. These courses can be either extremely valuable or a complete waste of time, but in any case they are almost always expensive. Wouldn’t it be nice to know you’re getting your money’s worth?

The good news is that choosing a technical trainer is like choosing any other service provider. A little due diligence up front can greatly increase your chances of having a good experience. Being a trainer myself, I was curious to see if there were any good articles I could recommend to guide potential clients through this process. Unfortunately my searches led me to sites for either personal trainers or dog trainers. Definitely not what I was looking for!

So here are my thoughts on choosing a technical trainer. I should say up front that I have an ulterior motive in writing this article. I want to see the quality of technical training improve, and the best way for that to happen is to demand more of trainers. If we all exercise more due diligence in selecting technical trainers, training providers will be forced to improve their offerings.

Creating the short-list

The first step in a trainer search is obviously to create a list of potential candidates. Most likely this will involve an internet search that will result in a short-list of trainers. So what should you be looking for when browsing websites at this stage of the process?

• Does the site have a professional look and feel? This is kind of a no-brainer in any search, but its especially important for trainers. At its core, training is about organizing and communicating information. If a trainer’s website is confusing, hard to navigate, or just plain ugly, it’s likely that the training materials will be as well.
• Does the site reflect a core competency in the area in which you need training? If a trainer provides courses in everything from C++ to Microsoft Word, you might want to look somewhere else. Oftentimes these one-stop-shops are really just brokers who will try to find an actual trainer once you’ve indicated some interest. It may take a bit more effort to make a direct connection with a trainer, but you’ll probably have a better experience if you do.
• Does the site contain articles or blog posts relevant to the training area? Many do not and I wouldn’t exclude a trainer for that reason. But if articles do exist, they can be a good window into the trainer’s mind. If articles do exist, examine them for clarity and thoughtful presentation. This can be especially useful when you’re considering hiring a “guru” to do training. While it’s always tempting to hire an acknowledged expert in the field, some gurus make good trainers and some do not.

Getting to know the trainers – asking the right questions

Once you have a short list of trainers at hand, it’s time to get to know each of them. What should you be looking for? Well, the value of the training you receive will depend on the quality of the trainer and the training materials. You should try to find out as much as possible about both.

First, the trainer. You may have noticed that I’ve been consistently referring to trainers as opposed to training providers. It’s important to understand that even if you’re talking to a large training provider, what you are really selecting is a specific trainer. Ask up front who the trainer will be, and if that does not go over well you may want to look elsewhere.

If on the other hand you are presented with a specific trainer, ask if you can interview this person. If you have a technical expert available, you may want to have them sit in on the interview to assess the trainer’s knowledge. In any case, though, you should be looking for communication skills. Does the trainer speak simply and clearly? Is he or she eager to explain things in a way you can understand? Would you want to listen to this person talk for days at a time?

And the training materials? These are critical to the success of the training course, and you should ask for samples that you can evaluate – some slides and a few pages of the manual and labs if relevant. Examine these samples for clarity and visual interest. Are they filled with text that the trainer will probably read verbatim or do they present visually interesting explanations? Text-heavy slides can lead very quickly to student fatigue and make the training less effective. Are the text and images presented in a professional manner and would they be easy to look at when projected? Again, would you want to look at these slides for a few days straight?

You’ll obviously receive other information about the training course, such as pricing and availability. But one thing you should always request is a list of recent references. This is such an important topic, I’ve saved if for last.

Calling the references

References should be an important part of your selection process. When you are provided with a list of references, call them. Please, please call them. There is no better way to get an accurate picture of what a trainer is really like.

I’ve found that many people do not call references either because they don’t want to impose or they think the process does not provide good information. If you feel this way, I urge you to reconsider. Most clients are happy to talk and the process can be extremely valuable if you approach it correctly.

The first suggestion I’d make is to talk to people who were actually in the course. Many references you receive will be for a manager who arranged the training, and that’s fine. These references can provide great high-level information about the course, students reactions, and the success of subsequent projects. But it’s a good idea to ask for a few student references as well. There’s no substitute for talking to someone who was in the room.

Second, make sure that the references you’re talking to were taught by the specific instructor that will be teaching your students. Talking to references who had other trainers is of little value.

Finally, go beyond the “were you happy with the trainer” questions. A good approach to references is to get them talking about their experiences in very concrete ways. The best way to go about this is to ask specific questions. Here are some examples:

• Do you think the course materials were well designed and easy to follow?
• Were there students in the course who felt things were moving too fast or too slow?
• Did the trainer make any changes to the course to better meet your needs?
• Were there labs? If so, were they helpful and did most of the students finish them successfully? One thing to look for here is if the trainer fell back to doing the labs on behalf of the students, while everyone simply looked on.
• Was the trainer able to go beyond the material to talk about advanced topics?
• If the trainer did not have the answer to a question, did he or she promptly follow up with the answer?
• Has the trainer been responsive to follow up questions after the course completed?

It’s all about the students

In the end, the quality of a training course can only be measured by the effect it has on students’ life and work. When selecting a technical trainer, it’s important to always think about the needs of the students and to do whatever it takes to make sure they will benefit from the training.

Expect more from your technical trainers and I think you’ll be pleasantly surprised with the results.

People often ask me what’s so special about Eclipse RCP and what types of projects it’s useful for. Well here is one answer from EXTOL, a software company that is using Eclipse RCP as the foundation for it’s own products.

The short answer, which I like a lot, is:

Adopting Eclipse RCP gets us out of the framework business.

But please read the entire post for all the details. It’s well worth your time.

Well the results of the survey are in, and the clear favorite is the existing name: Eclipse RCP. While the original purpose of the survey was to create a short-list of names, I think the strong showing of the existing name means that the process should stop here. So long live Eclipse RCP!

For those of you interested in a summary of the results, 472 people took the survey (which is pretty good, I think). The top 5 name were:

1. Eclipse RCP – 169 votes
2. Eclipse Platform – 51 votes
3. Aurora – 48 votes
4. Corona – 38 votes
5. Tangram – 32 votes

There were also many write-in votes, some of which were kind of amusing:

1. Colbert (only 2 votes, sorry Stephen!)
2. AlBlue’s Big Bundle of Fun
3. Twilight

On a more serious note, I’d like to thank everyone who took the survey and all of those who expressed their opinion both publicly and privately. One of the great things about open-source software is that we are able to make decisions as a community, and I think this process has been a good example of that.

In my last post I discussed how to best manage run configurations for Eclipse RCP applications. But there was one related topic I wanted to discuss in more detail, and that is how to manage launch arguments.

What are launch arguments?

Launch arguments are arguments that are added to the command line when you execute your application. These arguments come in two flavors:

• Program arguments – Arguments that are Eclipse-specific. For example, the -clean argument will clear the configuration area on startup.
• VM arguments – Arguments that make sense to the Java VM. For example, the -Xmx argument allows you to set the maximum heap size for the VM.

Both of these argument types can be set on the Arguments tab in the Run Configurations dialog.

Launch arguments and the target platform

We oftentimes want to apply the same launch arguments to all of our run configurations, and one way to handle that is to specify them on your target platform. On the Target Platform preference page there is a section where you can add whatever arguments you wish.

The arguments associated with a target platform will be added to run configurations generated from the Manifest Editor. They will not be added to configurations generated by the Product Configuration Editor. Also, because the Manifest Editor link does not regenerate a configuration each time, you will need to explicitly delete a configuration if you want to recreate it using new target platform arguments.

Launch arguments and products

A second way to manage arguments is to add them using the Launching tab of the Product Configuration Editor.

When you add arguments in this way, two things will happen:

1. The arguments will be added to your run configurations if you launch using the link in the Product Configuration Editor. Because this link regenerates the run configuration each time, consistent use of the link guarantees that your configuration is in synch with your product definition.
2. The arguments will also be added to your deployed application in the form of an INI file. This is a nice feature, but it means that you need to be careful when adding arguments that are only useful during development. For example, you may want to use -clean to clear the configuration area when you’re developing, but you probably do not want to ship this argument to your customers.

Launch arguments best practices

My approach is to add arguments using the Product Configuration Editor and to always launch my applications using the link in that editor. This guarantees that my run configurations are always in synch with my product definition. I also take care to not add arguments that would be detrimental to a deployed application. Some, such as -consoleLog, I consider harmless in a deployed app and I just leave those in.

If for some reason I absolutely have to add an argument that should not be deployed, I usually clean it out of the INI file during the build process. It’s pretty rare for me to have to do this, though.