Ken's Digital Den

Specify package-export version using bnd wrap.

Create a property file specifying the package pattern and the version:

$ echo "Export-Package: *;version=3.1" >

Now pass the property file to bnd:

$ bnd wrap -properties myjar.jar

Java 7 (OpenJDK/IcedTea) for the BUG 2.0

NOTE: this post was originally at, however the webserver seems only intermittently available so I’m moving the post here.

For anyone interested in Java 7, I have built OpenJDK 7 (via IcedTea) for BUG 2.0 (Angstrom, armv7, Zero VM).  The binaries are available here.  The binaries are not provided as Angstrom opkgs, so the installation process is manual. This is because it was built natively on a BUG, rather than using the OpenEmbedded cross compiling build system.  You’ll also need to install libcups2 via opkg if you want to replace the Java 6 JRE to run BUG applications.  Here is my installation steps, assuming the j2re-image tarball is decompressed in /home/root:

$ mkdir -p /usr/lib/jvm/java-7-openjdk/jre
$ mv ~/j2re-image/* /usr/lib/jvm/java-7-openjdk/jre
$ rm /usr/bin/java
$ ln -s /usr/lib/jvm/java-7-openjdk/jre/bin/java /usr/bin/java
$ opkg install libcups2

Now if you restart Felix (via Knapsack if you are running a 3.0 release), you’ll notice that the JVM running is java.runtime.version = 1.7.0_147-icedtea-b147 via http://bug/support.html.  This is provided on an experimental basis and I would not be surprised if problems pop up!

An interesting benefit that IcedTea 7 provides (other than ARM compatibility via Zero) is alternative VM implementations CACAO and JamVM.  The binary build I have provided unfortunately does not include these but I’m going to try and build them.  Hopefully I can get Zero, Shark, CACAO, and JamVM all happily living inside the BUG!  🙂

Special thanks to for his invaluable assistance!

Fresh from the oven: Knapsack for Apache Felix

Both for my various weekend projects and on the BUG, I’ve been unhappy with the bundled launcher that comes with Felix.  Equinox is no better.  Typically people use the Eclipse tooling to create and configure framework instances, but when setting up for production or working with embedded targets this is often not possible. So I set out to make something that would allow me to easily get a framework up and running from the terminal.  Luckily, Felix has excellent embedding support and documentation so it was pretty easy to get started.

What is it?  Essentially an alternative launcher for the Felix OSGi framework (3.2.2) that uses the OS’s native shell for framework management, and creates all of the configuration files automatically, letting the user just download, run, and start adding their application bundles, with interactive feedback.

I’ve much more detail on the design details and usage on the project page and in the readme.

However, here is the summary of how to go from Zero to OSGi in 30 seconds*:

$ mkdir foo && cd foo
$ wget
$ java -jar knapsack.jar &

* Depending, of course, on your copy-paste skillz.

Release 0.1 for Sprinkles

After several months of actively developing with Sprinkles I think it’s time to make a tag and call it a version.  I’ve still got far to go in terms of documentation but with Cloudbees free Jenkins instance I have a build running with JUnit and Javadocs available.  I’ve also created a recipe for OpenEmbedded so embedded devices can also taste the functional fruits in Java.  Oh, and Sprinkles exports its package just like a good OSGi bundle should!

First look at the Globalscale Dreamplug

I have quite a few ARM-based devices in my office.  Some are for work, others are for fun.  One good thing about these little machines is that there is always room for one more.  A few days back I received the Dreamplug I ordered back in February.  It runs Ubuntu 9.10 out-of-the-box and sets itself up as a Wifi access point for easy connections.  This is a big improvement over the original beagleboard and other boards that expect the user to choose and burn a distro on an SD card before using the device.  I was able to connect the Dreamplug to the wall and ssh into the machine in a matter of minutes.  And being that it’s Ubuntu, which is a distro I am familiar with, I felt right at home.  Overall my impressions of the device are good.  The plastics are solid and the design is clean.  What attracted me to the Dreamplug however was some unique I/O it offers.  One problem with common ARM-based boards like the Beagleboard is that the USB/SD interface for storage is pretty slow.  This limits it’s utility when considering applications that require speedy file access.  I am currently using it to play music over the network, but I’d like to have some fast local storage to speed things up, and be able to play music without ethernet attachements.  Since the Dreamplug has built-in eSata, optical audio out, and wifi, it seems almost perfect for my application.

I have yet to test the eSata and optical out.  The wifi seems to work as advertised.  The base Ubuntu install is customized with a Globaltechnologies-developed wireless access point application that seems to handle the incoming connections.  I wanted to do away with this and just work wired initially, so I deleted the start script in /root that is run on boot.  I also opened up the device to get at the internal SD card.  To be honest, I bricked it early on when trying to change the subnet that the wireless network uses, as it conflicts with my internal network.  I was ultimately unsuccessful in changing this and decided just to stick with wired networking for now.

I also have a Dreamplug ancestor , the SheevaPlug.  This device is superior to the SheevaPlug in every way.  The design is better and the machine itself is bigger and faster.  And, except for video, pretty much all I/O options are covered for a device of this nature.

I may post more info about this device as I become more familiar with it.  Here are some photos of the Dreamplug.

The box

USB, optical audio, JTAG, serial, reset, ethernet ports. iPhone 3GS stacked on top.

Audio in/out, eSata, SD, and USB

Top of Dreamplug with iPhone 3GS for size comparison.

Power adapter. Note how the device does not sit flat on desk when power adapter is used.

Another shot with iPhone to show thickness.

Innovative! The power supply is detachable. Unfortunately the cable is too short to be of much use.

Internals. Note the microSD card on the separate board. Just the standard FAT/Ext3 kernel/rootfs partition scheme.

Closeup of the top of the board.

Bottom of the board.

Power supply options.

New software for an old BUG

created on: 05/04/11While the BUG 2.0 hardware platform is the shiney new toy everyone wants/NEEEDS, what can we say about our trusty BUG 1.x devices sitting around?  I think they are in need of some love, and as a community effort, have released some alpha-level builds of BUG 2.0 software for BUG 1.x hardware.  The project is called leafcutter, and the idea is that your BUG 1.3 device should be able to run all the BUGapps that your 2.0 device does, assuming you have the necessary modules.  The main work involved in this is migrating from the legacy Poky 3.0 build system to the OpenEmbedded 2011-stable build system.  The result of this migration means:

  • Up to date packages
  • A “living” distro, where contributors are adding packages all the time
  • OSGi R4 implementation (Apache Felix)
  • OpenJDK (Java 1.6)

I’m planning on having Dragonfly SDK support available, so development is seemless between hardware versions.  Have a look at the project page to see the current state of things.  Since this is not an official Bug Labs project, the sources are being hosted at Gitorious instead of the Bug Labs GitHub repo.  While the project is in an early stage, the basic Linux environment and OpenJDK JVM are currently working.  Depending on your needs, this may already be enough for some users to migrate.

And as a community-hosted project, everyone is welcome to contribute!  Areas that need attention:

  • Abstracting and isolating BUG 2.0 HW APIs from 1.3 HW APIs in the OSGi layer
  • Fixing and enhancing the windowing system
  • Providing an ‘extras’ package repository
  • Testing kernel and module support
  • Testing existing BUGapps on BUG 1.3 hardware

The start page has all the details regarding building and getting access to ready-to-install binaries.

Git in here you little rascals

I seem to have ascended to that (low) level of Git aptitude that makes me want to stick any old thing into a git repository.  Namely, the “dotfiles” or things that live in my home directory that tend to follow me around from machine to machine.  There are various established ways of doing this, including symlinks and scripts.  Due to Git not permitting the cloning of a repo into a non-empty directory, the process becomes more complex that it should be.  After an hour of bungling, my approach has become:

1) My central repo is not public (aka github).  So, I don’t need to worry about stray personal info being accentially dangled in front of the world.

2) No scripts or symlinks, the home dir is the repo.

My process:

1) On the new machine/account, get my ssh keys on there stat.

2) git clone <secret git repo>/homedir && cp -r homedir/* . && cp -r homedir/.* .

3) rm -Rf homedir

4) log out/back in for freshness

Poof, that’s all.  Then, when inspiration strikes and I update one of my little treasures, the ol’ git push ‘n pull gets all my accounts synced up.