OSGi has been in the press a lot lately. Everywhere you turn, there is some new product or project adopting the technology. From Eclipse to Apache to Spring. From servers to desktops to embedded. OSGi enables the creation of highly modular, dynamic Java-based systems.

In honor of the Eclipse Galileo release, Jeff McAffer and I will be giving a free online OSGi and Equinox course on June 30th. The content will be based on the upcoming Equinox OSGi book and the Toast example used within the book:

Never heard of Toast? Well, it’s an example application for telematics. What’s telematics? Well, according to Wikipedia:

it’s the integrated use of telecommunications and informatics. More specifically it is the science of sending, receiving and storing information via telecommunication devices.

You tend to see telematics in car navigation systems… like OnStar. A typical telematics system interfaces to the devices in the vehicle and provides some sort of user interface for interacting with or managing the devices. More sophisticated systems connect to a control center over a wireless network and allow remote control of the devices. Toast covers all of these bases as it interfaces to a simulated GPS and airbag system, provides a UI for a touch screen and communicates with an OSGi-based control center using a variety of protocols.

It’s a three hour course. The first two hours will be dedicated to covering OSGi topics, using Toast as an example. However, the last hour will be reserved to go over questions and what people suggest on this blog post’s comments. Note that we can’t cover everyone’s suggestions, but we’ll try to pick the best suggestions given the time constraints.

So what are you waiting for, please register and leave feedback on the blog!

We hope to see you at the end of this month!

Tags: equinox, OSGi

There has been a lot of talk lately about p2. Using p2, you can:

• Validate repositories
• Describe dependencies
• Manage your configurations
• etc…

However, all this talk about p2 assumes you have p2 enabled repositories.

Now p2 is able parse and understand traditional update sites, but this far from ideal for several reasons:

• The parsing / processing happens each time a user hits your update site. This means that jars are D/L and metadata is produced while users wait.
• Not all the information is available on an update site
• The cool kids already have p2 enabled repositories

So this begs the question:  How do I provide a “p2-ified” repository for my content?

In Eclipse 3.4 the answer was the metadata generator. The metadata generator was able to look at an Eclipse install, scrounge around the filesystem, crack open jars, and build a p2 repository from what it found. While this worked, it was very much tied to the way Eclipse is laid out on disk. (OSGi bundles had to be in a directory called plugins, start levels had to be listed in eclipse specific locations, etc…).

The metadata generator was written to give the p2 team the original “wad” of metadata so the rest of p2 could be assembled. The generator served it’s purpose.

In Eclipse 3.5, the p2 publisher was developed. The publisher is the means by which deployable entities get added to repositories. The publisher can be used in four ways:

• As a set of headless Eclipse applications
• As a set of Ant tasks
• Through its extensible API
• Within PDE Build

Today I’m going to discuss the first two:

Headless Eclipse Applications
There are four headless publisher application: 1. UpdateSite, 2. Features and Bundles, 3. Product, and 4. Category Publisher. Each of these publisher applications are responsible for creating metadata from different sources. For example, the Features and Bundles Publisher Application generates metadata from pre-built features and bundles.

This can be invoked as follows:

java -jar /plugins/org.eclipse.equinox.launcher_*.jar
-application org.eclipse.equinox.p2.publisher.FeaturesAndBundlesPublisher
-metadataRepository file://repository
-artifactRepository file://repository
-bundles /
-configs gtk.linux.x86
-compress
-publishArtifacts

This will create both a metadata and artifact repository for the bundles located in <location of your bundles>.  The repositories will be compressed and the artifacts (the actual bits) will be published.

Ant Tasks
In addition to the headless applications, the publisher can also be used directly in your Ant scripts. There are currently two Ant tasks provided by the publisher: 1. Features and Bundles, and 2. Product Publisher. These tasks do the same thing as their headless application counterpart.

For example, the feature and bundles task can be written as follows:

<p2.publish.featuresAndBundles
metadataRepository="file:/repository/location"
artifactRepository="file:/repository/location"
publishArtifacts="true"
compress="true"
source="/bundles/and/features/location/">

In this case the source tag is used, meaning that the publisher will look for both the features and bundles in the /bundles/and/features/location. It will look in a plugins directory for bundles and a features directory for features. Again, the repositories will be compressed and the artifacts published. You can use a nested <bundles> or <features> tag if you want to specify specific bundle or feature locations.

<p2.publish.featuresAndBundles
metadataRepository="file:/repository/location"
artifactRepository="file:/repository/location"
publishArtifacts="true"
compress="true"> 
  <bundles dir="/bundle/location"/>
</p2.publish.featuresAndBundles>

For more information on what the publisher is, how to use it, and how you can get involved, please read our wiki page.

Tags: equinox, OSGi, p2

… and yes, this is a workbench. As part of the Galileo release train, we will publish RAP version 1.2 and it has some cool new features. One of the bigger changes is the new look and feel.

RAP 1.2 default look and feel

You can apply this design very easily without changing a single line of code!

Just get the RAP 1.2 RC3 build and update your launch configuration. Then, you have just two more steps:

1. Add the bundle org.eclipse.rap.design.example to the bundles tab
2. Switch the servlet name in the main tab to ‘business’

To see the new design in action without checking out the code you can watch a screencast made by Elias (Thanks!).

Note that the screencast was made for RC2, we renamed the bundle in RC3.

To implement this design we utilized the new interaction design API. It’s a fully functional Eclipse workbench, without any hacks or other crazy stuff. It’s a production ready API. Thats all for now. Enjoy the new RAP look.

Please feel free to post your feeback and questions.

Tags: galileo, rap

One of the things I really like about my job is that I get to spend time working with students. As a software engineer working at EclipseSource Victoria, I spend part of my time at the University of Victoria helping master’s and PhD students with their research. I have also taught and TA’d a few course at both the University of Victoria and the University of Waterloo.

One of the things I don’t think we teach very well at University is software components and modularity.  Students get a brief introduction to the concepts in their first year data structure courses.  In these courses students are  taught that if you “hide the internals” and code to a “known interface” then the implementation can be changed.    This is often demonstrated by showing them how you can create a stack using an array, and without the client knowing, the stack can be changed to use a linked list.

While it is important that students learn this, there is no practical way you could replace the implementation in any binary compatible way without considering a number of other factors.  And while the example may barely work for a stack, it doesn’t scale to anything larger than a single class.  It is often explained that packages and jars are the next abstraction up, and students are told that things generally work the same.  The truth is, packages and jars are a pretty poor form of software modularity.

I have decided to put a lecture together to demonstrate software components and modularity in the large. Enter OSGi.   Since OSGi has been around in one form or another for over 10 years, I thought it was about time students (and more importantly faculty) see how it provides a scalable method for software modularity.

The lecture hits three main points:

1. Versions.  While not necessarily an OSGi thing, the concept of versioning your API (both by versioning bundles and packages), and evolving your version number in a controlled manner (Major.Minor.Service.Qualifier) as your API evolves, allows consumers to understand and adapt to API changes.
2. Explicit Dependencies.  Since software components are rarely built in a vacuum, it is important to explicitly state what you depend on.  This allows your consumers to understand what you provide and what you require.  Instead of just dropping in the updated Stack bundle, the consumer can verify that they have the required linked list bundle.
3. Information Hiding.  Every first year will tell you that information hiding is a fundamental principle behind data abstraction.   Why languages don’t support information hiding at all levels of abstraction is  beyond me.   I demonstrate how OSGi supports internal / external (and x-friends) packages, and how these can be used to design reusable components.

I also talk a bit about bundle life-cycles, services, and class loading, but the bulk of the talk focus on the three points listed above.

if you were teaching OSGi 101, what would you cover?

What are your top 3 points?

Tags: OSGi

If you are at JavaOne, drop by the Eclipse Foundation (Mo 5-7pm, Tu 11:30-1-30) or EclipseSource booths (all week) for a demo of the Rich Ajax Platform (RAP).

In my demos, I’ll focus on the CSS customizations and enhanced theming capabilities that ship with the new with RAP 1.2 release (Galileo).

Here’s a screenshot showing a ‘RAP Addressbook’ application:

It is inspired by Kai’s recent work on the E4 Contacts Demo, but based entirely on my own codebase. I wanted to use a slightly richer data-model and UI, as I want this to become a replacement for the dated ‘Palm Desktop’ application I’m using. What you see is my progress after one day of work. It’s still very alpha, but you can get the code on github.

The second screenshot shows the same app using the new ‘business’ example theme:

With RAP 1.2, we have added the ability to customize the header, footer and part-stacks of the application. This is build on top of the Platform’s Presentation API but with our own extension points that should simplify things. You can find this under ‘org.eclipse.rap.design.example’ in the RAP CVS. Look forward for a blog post decicated to this topic later this week.

See you at Java One!

Tags: eclipse ui, galileo, rap

I highly recommend that people take a look at the ‘Eclipse on Rails and Rockets‘ EclipseCon 2009 talk. It’s exciting to see what consumers of Eclipse technology have been doing. In the first part of the talk, we learn that the Swiss Federal Railway has been using RCP to monitor trains…

In the talk, I was amazed to learn that a lot of this process used to be done by hand before:

Thankfully, they decided to use Eclipse RCP with cool visualizations and a lot of workbench windows:

For the second half of the talk, we got a peak at what NASA has been doing for the past 5 years with Eclipse RCP. In particular, the work with the Mars Exploration missions was mesmerizing to watch (zoom in on that surface!):

The NASA folks also discussed how they are using Eclipse in other missions now:

In the end, the NASA folks presented a slide which tickled my interest:

From what I understand, it looks like NASA has grasped the benefit of building platforms. Platforms are all about components. Once you start building components (via Eclipse/OSGi), it’s easy to see how a platform can materialize. I would be curious to see if NASA has a “platform team” internally now that is responsible for their Eclipse-based technology to be consumed by other NASA departments.

So what are you waiting for… sit back for about 40 minutes and enjoy a great talk!

Tags: eclipse, nasa