Francisco Benitez Leon's Blog

Installing Debian Lenny on virtualized ARM arch (with QEMU) on Ubuntu Karmic Koala

Francisco Benitez Leon — Fri, 05 Feb 2010 21:42:47 +0000

Yesterday I played with QEMU in order to run a Debian Lenny distro on a virtualized ARM arch. The Debian installation was easy thanks to this post of Chris Dew. I just wanted to point out what I did to get the virtual machine running after installing the distro.

First, I’ll summarize his post because I changed one of his steps.

Download the ARMEL kernel image and installer (initrd image) from a Debian Lenny repository.
$ wget http://ftp.de.debian.org/debian/dists/lenny/main/installer-armel/current/images/versatile/netboot/initrd.gz $ wget http://ftp.de.debian.org/debian/dists/lenny/main/installer-armel/current/images/versatile/netboot/vmlinuz-2.6.26-2-versatile
Create a disk image but use the raw format so you could mount it on your system after the installation process has finished.
$ qemu-img create -f raw hda.img 1G
Start QEMU and follow the usual Debian installation instructions.
$ qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.26-2-versatile \ -hda hda.img -initrd initrd.gz -append "root=/dev/ram" -m 256

At the end of the installation process you will get a message pointing that Grub hasn’t been installed but don’t worry because QEMU is capable of loading the kernel and initrd images so the machine could boot up.

After the installation has ended you will need another initrd to run the machine, remember that the one previously used contains the Debian installer. You can get that from the installed distro. So, mount the created disk on your system (that’s why you needed to create it in raw format) and copy the image from the boot directory.
$ sudo mkdir -p /mnt/arm_qemu $ sudo mount -o loop,offset=32256 hda.img /mnt/arm_qemu $ sudo cp /mnt/arm_qemu/boot/initrd.img-2.6.26-2-versatile . $ sudo umount /mnt/arm_qemu

You can run the machine with the following command.
$ qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.26-2-versatile \ -initrd initrd.img-2.6.26-2-versatile -hda hda.img -append "root=/dev/sda1"

Filed under: ARM, Virtualization Tagged: Linux, QEMU

Giving a hand with JMUnit

Francisco Benitez Leon — Tue, 22 Sep 2009 17:46:44 +0000

I don’t know why I haven’t blogged on this before but that’s it, I was added as a developer of the JMUnit project three weeks ago. I posted in the JMUnit forum about the patch I made to avoid the TestSuite execution problem and four days after I was discussing JMUnit 2 features with Carl A. Meijer (one of the administrators of JMUnit). Carl was kind enough to contact me, suggest me how to enhance the patch runners and include me as a member of the project. Not only I am enjoying working on JMUnit but I am also learning a lot in the process. Thank you Carl!

JMUnit 2 looks promising and JMUnit 1 users will love the new release. It will include new features, solve known problems, as the TestSuite execution one, be more convenient to use and, besides that, porting your old tests will be plain and simple. The code is almost finished and the delay in releasing it will lie in the proof-of-concept plug-ins we want to include for Eclipse and NetBeans.

Hopefully, you will be able to use JMUnit 2 soon.

Posted in Mobility Tagged: JMUnit, Testing

Revisiting JMUnit, JMUnit Revised 2.0

Francisco Benitez Leon — Sat, 15 Aug 2009 18:04:56 +0000

Some days ago I published a post introducing a patch for JMUnit that I use for being able to execute TestSuites. After releasing the patch, I tried to integrate it into NetBeans hacking the mobility pack to get the patched library working with the mobility wizards for creating unit tests. However, due to the design of the patched sources it was impossible to achieve. I also detected a problem with the design that was preventing TestSuite from creating the TestCases read from the Application descriptor (I have never used the custom property JMUnitTestClasses since I started using the modified JMUnit sources).

Based on the general idea of eliminating MIDlet from the inheritance chain I have redesigned the patch, instead of passing a MIDlet to Test in its constructor, Test has to be initialized with a MIDlet before creating any Test object (TestCase, TestSuite or TestRunner). The new desing doesn’t break any of the features of JMUnit, its usage is much simpler and it can be almost fully integrated in NetBeans, as I will explain next week.

You could download the patch and know more of this new release at JMUnit Revised 2.0.

Posted in Java ME Tagged: Development, JMUnit, JMUnit Revised, Testing

Integrating S60 3rd Edition FP1 SDK for Symbian OS with NetBeans IDE 6.5

Francisco Benitez Leon — Wed, 12 Aug 2009 22:17:05 +0000

Recently I broke part of my developing environment consisting of a NetBeans IDE 6.1 installation, on Windows XP SP2, in which I had integrated several Java ME platforms for developing mobile applications. I tried to install the S60 5th Edition SDK for Symbian OS without paying to much attention and trying to fix the mess (I wasn’t able to launch applications on the SDK from NetBeans) I ended up breaking two more platforms, the S60 3rd Edition FP1 SDK for Symbian OS and the FP2 SDK.

I decided to reinstall the platforms and I thought it was worth upgrading the IDE, so I tried to set up the same environment with NetBeans IDE 6.7 and the S60 SDKs. Unfortunately I had no success, I’m not sure but I think it was because of the ActivePerl version. The S60 3rd Ed. FP2 requires ActivePerl 5.6.1.638 or newer and the S60 5th Ed. SDK requires exactly the 5.6.1 version, I had installed ActivePerl 5.10.0.1005. At this time I had to reinstall again so I used google and read that the NetBeans recommended version for S60 5th Ed. was 6.5. You know how this end, I set up the environment correctly with NetBeans IDE 6.5. I added the three S60 SDKs as Java ME platforms to NetBeans and tested all the configurations. You have to be patient with S60 SDKs as they all emulate the complete Symbian OS and have a long startup time. Sometimes the first time you launch an application on the emulator from the NetBeans, a NullPointerException is thrown because the emulator takes too long to start. In these cases I relaunch the process and everything works like a charm.

So I had all my new development environment set up and working, and then …

… I realized of the NetBeans’ Project Platform Properties window for the S60 3rd Ed. FP1 SDK, where were the optional packages?

NetBeans Project Platform Properties window for S60 3rd Edition FP1 for Symbian OS, most optional packages missing

The fact is that it seems that the Optional Packages choice group is not working properly for this Java ME Platform. The only package that is selectable is the Java ME Web Services package but whether you select it or not it is always present. You could check it adding the following lines to one MIDlet:

import javax.xml.namespace.QName; //part of JSR-172 Java ME Web Services
...
          public void startApp()  {
                     ...
                     QName test = QName("test");
                     ...
          }
...

It will compile whether you checked the JSR-000172 or not, it is enabled by default as you will see. This is an inconvenience as I don’t want to add more libraries than the extrictly necessary.

I didn’t want to reinstall again so I added the platform to my NetBeans 6.1 and looked at the Project Platform Properties window, and all the optional packages were selectable. I guess that something had changed in NetBeans from versions 6.1 to 6.5 that was preventing the IDE from discriminating among these optional packages.

I am going to tell you how I managed to solve this problem but if you don’t know how to add the platforms to the IDE you could follow these guidelines first.

Making S60 3rd Edition FP1 SDK optional packages selectable from NeatBeans 6.5

To be successful you’ll need to have installed NetBeans IDE 6.5, S60 3rd Edition FP1 and FP2 SDKs (first install the IDE and next you should install the SDKs following its installation instructions). The SDKs have to be integrated with NetBeans as Java ME platforms, and at last you’ll have to do a little hacking with the SDKs and NetBeans to get it working.

The Java ME platform configuration files in NetBeans are located in:

%USERDIR%\.netbeans\6.5\config\Services\Platforms\org-netbeans-api-java-Platform

, you will see one for each Java ME platform you have added. Before going any further you should spend some time understanding the NetBeans Java ME Platform definition DTD 1.0 which is really simple. Here is a brief formatted description of the main elements presented in the DTD:

Element platform – defines the Java ME platform with the following attributes:
- name – identification of the platform. The platform is always referenced by the name so the name must be unique among all installed platforms within the IDE.
- home – base folder of the platform installation.
- type – platform type. Valid values are currently: UEI-1.0, UEI-1.0.1, and CUSTOM.
- displayname – displayed name of the platform. When not specified name is used instead.
- srcpath – optional list of folders, jars and zip files with platform sources.
- docpath – optional list of folders, jars, zip files and URLs containing platform JavaDoc.
Element device – defines the devices supported by the Java ME platform, with the following attributes:
- name – device name is the unique identification of the device within the platform.
- description – optional description of the device.
And the following elements:
- configuration – Java ME device configuration. It should be at least one present. Its attributes are:
  - name – configuration name will usually be CLDC.
  - version – version number in text format. For example: 1.0
  - displayname – expanded name of the configuration. For example: Connected Limited Device Configuration.
  - classpath – comma separated list of folders, jars and zip files that belong to the configuration.
  - default – boolean specifying if this configuration is default. Valid values are true or false. Exactly one configuration must be set as default.
- profile – Java ME device profile. It should be at least one present. Its attributes are:
  - name – profile name will usually be MIDP.
  - version – version number in text format. For example 1.0.
  - dependencies – list of configuration dependencies.
  - displayname – expanded name of the profile. For example: Mobile Information Device Profile.
  - classpath – comma separated list of folders, jars and zip files that belong to the profile.
  - default – boolean specifying if this profile is default. Valid values are true or false. Exactly one profile must be set as default.
- optional – Java ME device optional packages. It could be present none, one or more. Its attributes are:
  - name – optional API name, for example MMAPI.
  - version – version number in text format, for example 1.0.
  - dependencies – list of dependencies on configurations, profiles, or other optional APIs of the same device.
  - displayname – expanded name of the optional API. For example: Mobile Media API.
  - classpath – comma separated list of folders, jars and zip files that belong to the optional API.
  - default – boolean identification specifying if this optional API is enabled by default. Valid values are true or false. Any number of optional APIs may be enabled by default. As I told you before, in the added S60 3rd Edition FP1 SDK all the optional packages are enabled by default.
- screen – device screen details. If present there shouldn’t be more than one. Its attributes are:
  - width
  - height
  - bitDepth
  - isColor – true by default
  - isTouch – false by default

Now that you are an expert on NetBeans Java ME Platform definition DTD 1.0 we could go on and inspect the S60 FP1 platform XML configuration file. In my case is named S60_3rd_Edition_FP1_SDK_for_MIDP.xml and its content, skipped the S60Device section for clarity, is:

...

As you can see all the optional packages are bundled with the configuration (CLDC 1.1) and profile (MIDP 2.0) in the file hmidps60v31.jar. This is because the SDK implementation presents its complete Java ME execution environment in one jar.

In the case of the S60 FP2 platform most of the optional packages are standalone jars, as you can see in its NetBeans’ Java ME platform configuration XML file, named S60_3rd_Edition_SDK_for_Symbian_OS__Feature_Pack_2_v1_1.xml:

...

This seems to confirm the hypothesis about the bundled jar with the optional packages being the cause of the problem. To make them selectable in the Project’s Platform Properties window you’ll have to copy, for the optional packages in S60_3rd_Edition_FP1_SDK_for_MIDP.xml, the standalone jars from the S60 FP2 SDK lib directory (e.g. C:\S60\devices\S60_3rd_FP2_SDK_v1.1\lib) to the S60 FP1 SDK lib directory (C:\S60\devices\S60_3rd_MIDP_SDK_FP1\lib).

To know which jar you’ll have to copy from S60 FP2 lib to S60 FP1 lib you should consult the NetBeans Java ME Platform configuration file for the S60 3rd Edition FP2 SDK, S60_3rd_Edition_SDK_for_Symbian_OS__Feature_Pack_2_v1_1.xml. For example, to know which jar I should use as S60 3rd Edition FP1 SDK Java ME Web Services (JSR-172) I look for this optional package in S60_3rd_Edition_SDK_for_Symbian_OS__Feature_Pack_2_v1_1.xml and copy the required jar, JSR172.jar, from the S60 FP2 lib to the S60 FP1 lib directory.
copy %S60_3RD_EDITION_FP2_SDK_HOME%\lib\JSR172.jar %S60_3RD_EDITION_FP1_SDK_HOME%\lib
Where,

S60_3RD_EDITION_FP1_SDK_HOME = C:\S60\devices\S60_3rd_MIDP_SDK_FP1 is the HOME path for the S60 3rd Edition FP1 SDK.
S60_3RD_EDITION_FP2_SDK_HOME = C:\S60\devices\S60_3rd_FP2_SDK_v1.1 is the HOME path for the S60 3rd Edition FP2 SDK.

Next, you should update the S60_3rd_Edition_FP1_SDK_for_MIDP.xml file with these new libraries or add a new Java ME platform. I chose to add a new one named “S60 3rd Edition FP1 SDK for MIDP New” and leave unchanged the original one:

...

You should use these new libraries with caution as you have added jars that could have parts which aren’t compatible with the S60 3rd Edition FP1 Java ME execution environment. This is the case of the midp21.jar used for the MMAPI.

If you want you could also update the corresponding documentation setting the attribute docpath of the element platform in the Java ME platform configuration XML file (this property is not set in the above example).

Once this has been done, go to your Project’s Platform Properties window and watch the results:

Netbeans Project Platform Properties window for S60 3rd Edition FP1 for Symbian OS with selectable optional packages

Now you will be able to select the optional packages that you need. I have tested some applications built with this modified platform and seems to work well on both emulators and real devices, but the truth is that I have not done an extensive testing with all the APIs.

If you have any problems and want help or if you know a more stylish way of solving this inconvenience, let me know.

Posted in Java ME Tagged: Development, NetBeans, Nokia, S60, Symbian

Surpassing JMUnit CLDC 1.1 TestSuite execution barrier on real devices

Francisco Benitez Leon — Tue, 04 Aug 2009 18:07:33 +0000

If you have developed Java ME mobile applications and you have used JMUnit for unit testing (which I strongly recommend), you would probably have noticed that TestSuites can’t be executed on some real devices (as Nokia® or Motorola® mobiles) and simulators/emulators (as Symbian 3rd Editon FP1 and FP2 or Java ME SDK) . This is due to the fact that MIDlets can’t create other MIDlets for security reasons (as stated in JSR118 only the application management software can do this), so if you try it you will get a SecurityException.

As explained in JMUnit manual section 3.1, the problem is that TestCase and TestSuite extends Test, which extends Assertion, which extends MIDlet =). So with any TestCase that you add to your TestSuite (which is already a MIDlet) you are adding another MIDlet and that’s why you would get a SecurityException when executing your TestSuite. To avoid this you will have to modify JMUnit source code and break this inheritance chain.

The process to break the chain is really easy: eliminate MIDlet from the inheritance chain, pass a MIDlet reference (midletRef) to whichever classes that use MIDlet’s methods and substitute these methods invocations for midletRef.method(). There’s one step more after breaking the chain as there is another class that uses MIDlet via Test, GuiListener has to be modified too.

I have complete this process in a project called JMUnit Revised. You could take a deep look at the process followed to modify JMUnit1.2.1 CLDC1.1 sources, download a patch and consult the usage at JMUnit Revised project’s page at my personal site. After creating a jar with the patched JMUnit1.2.1 CLDC1.1 sources and following the usage instructions you will be able to run your TestSuites on most real devices and simulators/emulators.

Now keep up happy testing!

Posted in Java ME, Mobility Tagged: JMUnit, JMUnit Revised, Nokia, Testing

Hello World! Where will this be going to?

Francisco Benitez Leon — Wed, 29 Jul 2009 09:45:48 +0000

Honestly, I can’t say at the moment …

But stay tuned to discover! And welcome!

PS – Meanwhile you can always take a look at the categories and tags on the side bar.

Posted in Uncategorized