"Long may your Jib draw" - A good wish for the future.

East coast of Newfoundland
 as seen from above.

"Long may your Jib draw" - A good wish for the future.

About a year ago I struck out on my own to begin my career as an independent consultant, providing services in software development and testing. It was an amazing experience. I had the opportunity to see all aspects of projects coming together, navigating changes, and seeing the finalized product reach my clients hands. During this time I kept one foot firmly in the Apache community while delivering services to my clientele, however these local projects rarely let me dive deeply into the Apache projects I enjoy so much.

As of this spring I've signed on with Savoir Technologies as one of their Computer Systems Analysts. In this role I will be able to expand my involvment with Apache projects on a day to day basis. I'm looking forward to meeting new people, and helping them navigate towards successful deployments of Apache based projects. If you'd like to touch base with Savoir regarding project services and training availability please visit http://www.savoirtech.com/about-us/contact-us.

Making OSGi deployments easier with feature files

Q: How can we simplify provisioning bundles?
A: We use feature xml files.

When developing OSGi applications developers often end up with a large number of components that need to be deployed together. Doing this in a piece meal fashion can quickly become error prone, to help over come this problem Apache Karaf contains the concept of a feature file.

A feature file is a simple xml file that lists a collection of bundles that should be deployed together. It's really that simple! To make things even easier, a feature file may also reference other feature files allowing a developer to wire together even larger deployments. It should be noted that feature files are just a collection of references to resources - it is not a self contained artifact representing a ready to run application, that capability is encapsulated by the Apache Karaf Archive.

Luckily we've made creating a feature project really straight forward in Apache Karaf via the Karaf Feature Archetype. The archetype, when invoked, creates a skeleton Maven project for building a feature file. Using features to organize your provisioning of bundles marks one of the best practices for provisioning OSGi applications on Apache Karaf. Generally if I have two or more bundles that I need to deploy together then I'll go ahead and create a feature file.

To use the archetype you'll need the following:

1. Java 1.5 or higher.
2. Apache Maven 2.2.1 or higher.
3. And Apache Karaf 2.2.6 kit or higher installed.

The general format of the archetype invocation for generating a feature project is as follows:
       mvn archetype:generate \
           -DarchetypeGroupId=org.apache.karaf.archetypes \
           -DarchetypeArtifactId=karaf-feature-archetype \
           -DarchetypeVersion=2.2.6-SNAPSHOT \
           -DgroupId=org.myorg \
           -DartifactId=my-feature \
           -Dversion=1.0.0-SNAPSHOT \
           -Dpackage=org.myorg.package

The command may look a little complicated but its mostly straight forward once you break it down into its parts.

The first three arguments to the archetype generate directive simply specify to maven which archetype to use, the next four arguments are what you're going to be most interested in configuring. The groupId, artifactId, version, and package should be configured to your own project name and versions.

Using the Karaf Feature Archetype to create Maven
feature project skeletons is easy!

Once you've invoked the command it will begin parsing your input, then ask to confirm its interpretation of your configuration before writing to disk a skeleton project. Once this is complete you'll have a new folder created that contains a pom file. This project can be built by running "mvn install", a feature file will appear in the target/classess directory.

The generated feature file can then be deployed by either coping it into Karaf's deploy folder, or by adding the feature file to Karaf via the features:addurl command, then issuing the features:install command for the feature. In either case the bundles specified in the feature file will be resolved, then started.

To help make things a little clearer I've included a feature demo in Karaf's demo/deployer folder (as of Karaf version 2.2.6). The particular feature project you'll find has been crafted to be as minimal as possible. You'll find a README file in the folder as well that outlines the instructions to build and deploy the demo feature.

Making an OSGi bundle using Apache Karaf 2.2.x.

How do I make one of these OSGi bundles?

I received a few private messages regarding my last Apache Karaf demo post asking a more fundamental question on making OSGi bundles for use with Apache Karaf - that is how to just make a standalone bundle?

Before I dive into the above question, if you're wondering just what OSGi is then please visit: http://www.osgi.org/About/HowOSGi.

To the unfamiliar an OSGi bundle is essentially a special Java Archive file. The basic premise behind the idea is to add a set of properties to a jar's standard Manifest file. These properties correspond to OSGi naming and versioning standards, it also includes a few properties that enable an OSGi container to manage dependencies for the bundles deployed inside it. Outside of these properties, little else differs, except for a special class that implements the Bundle Activator interface; this is used by the OSGi container as a hook into bundle's life cycle (one would normally specify a Main method to execute code from a jar, OSGi uses an implementation of the Bundle Activator interface which contains a start, stop, and other methods to control life cycle states). The class implementing the Bundle Activator interface is specified in the Manifest file so that the OSGi container may interact with it.

A bundle is built up from a collection of classes, resources, and a manifest file.

Well luckily we've made creating a bundle project really straight forward in Apache Karaf via the Karaf Bundle Archetype. The archetype, when invoked, creates a skeleton Maven project for building an OSGi bundle. This skeleton goes so far as to even generate a bundle activator for you. Personally, I find this methodology much easier than creating all the artifacts by hand ;)

To use the archetype you'll need the following:

1. Java 1.5 or higher.
2. Apache Maven 2.2.1 or higher.
3. And Apache Karaf 2.2.6 kit or higher installed.

The general format of the archetype invocation for generating a bundle project is as follows:
    mvn archetype:generate \
      -DarchetypeGroupId=org.apache.karaf.archetypes \ 
      -DarchetypeArtifactId=karaf-bundle-archetype \ 
      -DarchetypeVersion=2.2.6-SNAPSHOT \ 
      -DgroupId=org.myorg \
      -DartifactId=my-bundle \ 
      -Dversion=1.0-SNAPSHOT \ 
      -Dpackage=org.myorg.package
The command may look a little complicated but its mostly straight forward once you break it down into its parts.

The first three arguments to the archetype generate directive simply specify to maven which archetype to use, the next four arguments are what you're going to be most interested in configuring. The groupId, artifactId, and version are how you want your bundle to be named and versioned. The package argument is the name of the package you want the internal code to use.

Once you've invoked the command it will begin parsing your input, then ask to confirm its interpretation of your configuration before writing to disk a skeleton project. Once this is complete you'll have a new folder created that contains a pom file and src folder containing a sample activator class. This project can be built by running "mvn install", a bundle will appear in the target directory.

Using the Karaf Bundle Archetype to create Maven
bundle project skeletons is easy!

The generated bundle can then be deployed by coping it into Karaf's deploy folder or by invoking an install command on Karaf's console. When the bundle is started a message will be printed to the prompt, similarly when the bundle is stopped another message will be displayed (this behaviour can be removed by editing the start and stop methods of the Bundle Activator implementation).

To help make things a little clearer I've included a bundle demo in Karaf's demo/deployer folder (as of Karaf version 2.2.6). The particular bundle project you'll find has been crafted to be as minimal as possible. You'll find a README file in the folder as well that outlines the instructions to build and deploy the demo bundle.

Making an OSGi bundle out of a third party jar.

Apache Karaf 2.2.6 will contain a new deployer demo which illustrates making an OSGi bundle out of a third party jar.

The sample provided is not the only way to make a third party jar into a bundle, however, the methodology shown provides a developer a lot of control over the bundle produced while not having to perform all actions by hand.

The demo takes the Apache commons-lang jar and wraps it as an OSGi bundle. To do this a POM file is created that picks up the commons-lang jar, shades it, then packages it into a bundle. The shading and packaging into an OSGi bundle steps are performed by configuring the Shade and Bundle plugins.

The Shade plugin provides the capability to package an artifact in a special jar, including its dependencies and shade (rename) the packages of some of the dependencies. To achieve fine grained control over which classes from the selected dependencies are included, artifact filters can be used. It's beyond the scope of this post, or the Karaf documentation, to discuss how filters can be setup, more information can be found on the Maven Shade plugin example here http://maven.apache.org/plugins/maven-shade-plugin/examples/includes-excludes.html.

The Bundle plugin wraps the BND tool from Peter Kriens, providing Maven a convenient way to produce a bundle by describing its content. A developer can configure the plugin to set the bundles imports and exports, among other bundle properties. Again, it's beyond the scope of this post, or the Karaf documentation, to discuss in depth all the features of the bundle plugin. For more information please visit http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html.

The primary take away from the deployer wrap demo is to illustrate a repeatable process for wrapping your third party jars;

1. Define target jars to package into bundle.
2. Shade jars (renaming packages as needed).
3. Build bundle by describing properties.

The final step is to deploy the newly wrapped bundle into the OSGi framework and test out your configuration. With careful tuning most of your third party jars should be convertible into OSGi bundles - this being said, some jars may require even more special care to operate safely in an OSGi environment. In these cases it would be advisable to request the provider of the third party jar to produce an OSGi bundle.

Go Beyond Pixels Conference

Bruneau Centre, Memorial University

Go Beyond Pixels: A one-day conference for designers and developers.

HTML5, CSS3, Javascript, Mobile & App Development, UI, UX, Design, and More!

When: May 25th, 2012,
Where: St. John's, Newfoundland, Canada

The Go Beyond Pixels Conference will take place in the oldest English-founded city in North America. The venue for the conference will be the Bruneau Centre for Research and Innovation, Memorial University.

To register and purchase event tickets please visit:
http://gobeyondpixels.com/

Coffee shop wifi and open source development

Some recent events locally got me thinking about the importance of coffee shop wifi and open source development.
A few years back my friend Jon Anstey and I started working in our spare time on Apache projects - Jon on Apache Camel, and I on Apache Servicemix. We'd meet up on Water Street (downtown St John's) at Hava Java, a small coffee shop with free wifi, and pick an issue each from the project Jiras and hack away at them until we had patches ready to submit for review.
This continued for quite some time, eventually we both received invitations to our respective projects to join in as committers, the rest is history. The important part here is that we could spend hours and hours at local coffee shops using resources off the web while working on submitting patches. Those hacking sessions were instrumental in starting us off on the path to being contributing members of the Apache community. If no programmer space was available I'd have to wonder if either of us would have stuck as close to working open source projects as we did.
Today when I hear that a particular coffee shop (not Hava Java - they're awesome) may try to restrict the length of stay for those of us using coffee shop space for laptops and books I wonder how many good efforts could be impacted. Shoot, I wonder how much of Jon's book, Camel in Action, was written sitting down in a coffee shop? For that matter, how many Apache Karaf releases were kicked off while I've sat in a coffee shop?
Even though my early days as a new contributor with Apache are now behind me I still enjoy being able to meet up with other new contributors at coffee shops and be able to give them the benefit of having coding session with someone that can help show them the way. Take away these kind of informal environments and I fear the opportunities to expand our local open source community begins to fade away.

Update:
The story aired on the local CBC news. The impart of social media can be felt in a small town like St John's.

Enjoying Humble Pie

As mentioned in the comments, and the CBC report, the coffee shop offered up "Humble Pie" to students for two weeks in apology for the treatment a few experienced.
To be fare, I was there during an off hour, but I could see why people would enjoy the comfortable seating and large tables for spreading out their notes & laptops. As long as people treat the establishment with respect and not take up space for an inappropriate length of time (for the sake of argument, well past the time it takes you to enjoy a cup of coffee and slice of pie) than incidents like this should not occur again.

So, talking of Coffee Shops with free wi-fi - which coffee shops in town do you frequent when you want to get a little coding done?

IGDA Newfoundland Chapter Game Jam

I've collected all the information I could regarding the up coming Game Jam being held by the International Game Developers Association Newfoundland Chapter. Please visit the event link for more details.

From the IGDA-NL Game Jam event page:
"Times still need to be confirmed [tentatively Friday, 20 April 2012 at 18:00 until Sunday, 22 April 2012 at 16:00], but time is running for almost 48 hours. Bring your computer setup (laptops recommended), power bar and get ready to make games over the weekend. Collaborate with your neighbours and you'll be amazed at what you can make!"

Please visit the Facebook event to register your interest in participating.
Facebook event: https://www.facebook.com/events/360617653970900/

The following is a presentation that was presented at the last IGDA-NL meeting:

Game Jam IGDA Newfoundland

View more presentations from Janice Hertel

Preparing for Apache Karaf 2.2.6

The sixth maintenance release of the Apache Karaf 2.2.x branch has entered the planning phase, as such I'm preparing for the release management role.

To prepare I've selected a bottle of Finca Flichman Misterio Malbec 2011 to decant while listening to some Sam Roberts albums. As it has been a common thread on my last few 'preparing for Apache Karaf' posts, the 3.0.0 release is still underway in preparation - the community is committed to seeing Karaf 3.0 being feature complete and polished before it is raised to production status. In fact the Karaf 3.0.0 process will have an important impact on the 2.2.6 RC - we're going to hold off performing the 2.2.6 RC until the Karaf 3.0.x branch has at least been created. It is hoped that by branching Karaf 3.0.x from trunk that we can focus on polishing 3.0.0 towards release, while trunk becomes 3.1.0-snapshot - the home of new features.

Current high lights of this patch include the new command "feature:chooseurl" (makes it easier to install well known features files), better shell script support for Solaris, several bug fixes, and numerous dependency updates (32 resolved issues and counting!).

The wine will of course only be sampled after being gave proper time to breath in its container, after the first release candidate has be up loaded for voting (see our release guide for more details on our process).

Unfortunately I can't share the wine with you, but I can share a few links to some Sam Roberts videos.


I'm looking forward to starting the 2.2.6 release process. I'll be posting updates to our Twitter stream (#karaf) and on our IRC channel (irc.codehaus.org #karaf).

CS Games Winter 2012 Team doubles competition is cancelled :(

I was just given the heads up that the Mun CS Games Winter 2012 Team (doubles) competition has been cancelled. The collected prizes will be saved for next semester, with the perishables being replaced.
I was looking forward to the competition, we'll have to try again come the Fall 2012 semester.
In the mean while, for those students interested in programming competitions there is a Game Jam coming up in town. The IGDA Newfoundland chapter will be holding the event in the near future, I'll post here to my blog when I have more details.

Some unscientific polls on Apache Karaf 2.x usage.

 In January of this year I started a pair of polls on the Apache Karaf LinkedIn user group, I thought I'd share the results as they stand now. Please note these are unscientific poll results - expect them to be wildly inaccurate as the sample sizes in both polls were very small and limited to the group members on LinkedIn.

 The first poll question was "When deploying Apache Karaf what is your most common operating system to target for production use?". LinkedIn only allows up to five options, so I choose five of the major operating systems I've seen in production use. In a sample size of 26 respondents 92% were deploying on Linux, with 8% on a Windows system. I was somewhat surprised to not see any representation for the Unix platforms, and only trace reports of Windows usage. I'm going to issue a follow poll question to further break down the usage of Linux platforms by distribution family, I think it'll be interesting to see if there is a specific distro that Karaf users prefer for their deployments.

 The second poll question was "Which version of the JVM do you use most commonly for production deployments of Apache Karaf 2.x? (vendor neutral, 32 and/or 64 bit)". The poll sample size was truly small with only 9 respondents, as such its difficult to make many statements other than Java 6 appears to the popular choice at present. 

Again, I must re-iterate that the above polls were un-scientific. The purpose of the above exercise was to create some sort of profile of common Karaf usage - which at this point in time appears to reflect Karaf 2.x running on a Linux based OS using Java 6. Once the Karaf 3.x series of releases are generally available it'll be interesting to reissue the above poll questions and see if the above preferences are maintained or if a shift in deployment pattern occurs.