The Groovy Maven Blackberry thing (written for Solaris SPARC from an Android touch screen)

I really want to follow up on my Groovy Maven Blackberry work and so far this is all I can do. Yesterday I managed to actually run it for the first time in over a year or two since I wrote it. My earlier blog post was completely inaccurate, indicating that all you needed is the plugin source. It has a HEAVY dependency on RAPC, and I am not authorized to distribute RAPC. (I am also not authorized to distribute breakfast cereal to to my children because I’m not as calorie conscious and portion aware as I should be… says the wife.) In order to actually use my plugin you have to create one of various “rapc-compile-tools” bundles and list it as a dependency of the plugin. It’s very important the you be version aware when building and listing the “rapc-compile-tools”. Let me elaborate.

My plugin looks in its CLASSPATH under a folder “/Blackberry-utils/” for the following files:
“rapc.jar”, “net_rim_api.jar”, “SignatureTool.jar”, “sigtool.csk”, “sigtool.db”, “sigtool.set”
In order for the magic to work you must create a Maven jar artifact which includes a “/Blackberry-utils/” folder holding these files. The plugin expands the files from the dependency into the system’s temp folder and then uses all of these files to actually perform the compile to cod format. It does a bunch of other (probably unnecessary) hickery-doodle to create a jar identical to what will be in the final cod.

What you need to do is download a version of the JDE. Then create a “Blackberry-utils” folder somewhere on your hard drive. Copy each of the above listed files into this folder then jar the folder. You can find most of them in your JDE download which can be expanded by running the installer. (See my earlier post about running the Simulator on Mac for details on running Windows installers on Mac.) The sigtool files are created after you build and receive a RIM certificate. (If you don’t have a RIM certificate you can fake these files by renaming empty text files but they must be present for the plugin to work.) Finally deploy the jar to your Artifactory (or other) Maven repository. If you don’t use a local hosted Maven repository then you can manuallly create a pom file place a copy in the jar (I forget exactly where it goes but I think it belongs under /META-INF) and place both the pom file and the jar in a Maven conventionally formed path under “$HOME/.m2/repo”. The final path will probably look like “$HOME/.m2/repo/your/group/artifactid/version”. It’s to your benefit to install Artifactory or something equivalent to simplify both this deployment and future license restricted dependencies like javax.mail and commercial APIs.

Its a rather involved process to create the rapc-compile-tools and I hope to simplify in the future. Also be version aware and you may want to create multiple versions of the rapc-compile-tools to support various Blackberry devices and OS versions. For instance, you may want to build version 4.3.0 for older Blackberry curve devices and 4.5.0 and 4.7 for the newer Storm, Bold, and Tour devices. What you DO NOT want to do is compile against 4.7 and deploy to a Storm running an older 4.5 OS. remember your target audience on blackberry is far less likely to update their firmware than an iPhone user. You’re also likely to run into users sporting the 4.2.1 and older OSes so use the lowest possible version of the RIM apis possible to build your application.

Blackberry Sims running on OSX!

Success at the 11th hour… literally! It is now 11pm and I get the Blackberry Storm simulator to pop up on my Macbook Pro Leopard install under X11. To say that this is chalenging is an understatement. However with a little patience you too can read the remainder of this blog post and and have the Blackberry Storm staring at you. (Also, wait for my followup when I revisit running RAPC under Maven.) The biggest challenge most people have running Blackberry sims on OSX is the particular sim itself. I’ve discovered that not all sims are created equal. Particular sims load while others kinda load while still others crash and burn. Follow the directions here and Download the exact version of the sim mentioned and you should be ok. Or, if you’re like me you won’t find the exact version. The example assumes Storm sim version 4.7.0_4.7.0.46 but I couldn’t find it. Instead I was successful with version Before that I got really close with the ol’ Sprint 8830- This one loads but gives me “Access violation reading from 0×00000024”. Many say you can get rid of this by running clean.bat but I couldn’t find it in my install. I also read that dedicating the process to a single core could help (Linux tip) but I couldn’t find a CPU affinity tool that runs on Mac. I remembered that I would get these kinds of errors in Windows when I had JAVA_HOME set to point to JDK6 or JDK5 depending on the sim. So I unset my JAVA_HOME but still got the error. Also the newer Storm version 5.0 gives me:
fixme:win:EnumDisplayDevicesW ((null),0,0×33ed40,0×00000000), stub!
fixme:file:MoveFileWithProgressW MOVEFILE_WRITE_THROUGH unimplemented
X Error of failed request: BadRequest (invalid request code or no such operation)
Major opcode of failed request: 128 (Apple-DRI)
Minor opcode of failed request: 7 ()
Serial number of failed request: 4685
Current serial number in output stream: 4685

I have a feeling there are a few other sims that work (try BlackBerry_Simulators_4.6.1.79_8350i.exe also listed in the example) but YMMV.

…And you’ll need to install MDS as well if you want any network access. Fortunately that’s not difficult at all. Just make sure you have JDK6 if you’re running a later version of MDS and recode the run.bat as an equivalent

Groovy Mobile Development On Maven For Mac

[click here to for the Subversion link to the Groovy Maven Blackberry Tools]

*Update* You do need to download and install the JDE or the Eclipse JDE plugin to be able to build a dependency for my plugin. I incorrectly stated this is optional below because it had been over a year since I used the tool myself. I am writing a followup post to elaborate on the inaccuracies.

…Because I couldn’t think of a dumber name. I’ve been sitting on this code for quite a while now. I’ve also been very busy. Busy learning/reading/writing JQuery/Java/Javascript for the MapQuest Local and Gasprices pages (my official means of keeping my house warm), busy fiddling with RubyCocoa, Objective-C and regular Cocoa on the side as my after hours pet-project, and busy trying to keep two crappy cars on the road while my hot water heater explodes leaking rusty wetness from years of neglect all through my finished basement while I sip Bud Ice a flight above completely oblivious to the disaster. (I’ve also been busy trying to put together some demo stuff for the kids at school… Cliff loves the kids like Martin.) What I haven’t been busy with is following up on the cool Blackberry stuff I used to do earlier this year. I’ve been watching my hit counters and page statistics climb up from the thirteen people that originally knew about me to a whopping 15.5 and I’ve been watching as those extra 2 1/2 people like to hang around my Blackberry posts. I’ve been feeling sorry for these 2 1/2 persons… particularly the 1/2 guy because his legs and lower torso will probably never grow back as he claws his way through the internets using that one good arm in a desperate attempt to pull his head and chest up to my home page expecting to finally see something worthwhile. (Thank you dearly Mr. Half-man-half-missing! I couldn’t have made 15.5 without you!!!) As a result I bring you today’s half-assed attempt at sharing my work.

I just committed three, count them, three maven plugins each written in Groovy over a decade ago (in computer years which is roughly 6 human months). These plugins are intended to make your mobile development life easier and, if you prefer Mac OSX, possible. I haven’t actually looked at the source code since they’d been written I just thought it was finally time to throw them out in the wild.

Maven Gant
So far I have a gant plugin which is something we use internally to launch Gant from Maven. I caution that I’ve found issues with the Groovy Maven support in that not all of the Groovy goodness is available such as the RootLoader and other things that I can’t remember hitting my head on. However it works for basic Gant builds and I think it makes its way completely through our complicated Maven/ant build wrapped in a Gant coating after we take care to explicitly file system load some extra Ant task jars. (Something about Maven calling Gant calling Maven calling Ant to load the Maven Ant tasks just doesn’t work right.)

Midlet Maven
I threw together a MIDlet helper Maven plugin to do OTA uploads to a slightly modified version of the Antenna OTA server. It should work with the official OTA server as well and if it doesn’t drop me a line and I can point to the single line of code that needs to be changed. I think it should do a PUT instead of a POST for the upload, my modified OTA server accepts either and I should just fix the dang file or post the modified OTA or both instead of rambling about it but since it’s easier to ramble than to do any real work, there ya’ go.

Blackberry Maven
This is my latest committed version of the Blackberry plugin for Maven. It’s the very same tool I used for compiling .cod files on my Mac way back. Alls yuh haff tuh do is install this Blackberry tools bundle in a secret location on your hard drive… or even better install a Maven proxy repo then pull the bundle from their. It’s simple yuh see… alls yuh haff tuh do is download something like Artifactory, unzip it, oh yeah… you’ll need something like Jetty to run the war file that you unzip… oops better grab Tomcat because I remember a lingering problem with Artifactory on Jetty, so yeah, get Tomcat right? Then configure it as a Windows startup service. Then maybe enable the admin and manager console cuz you’ll need to admin and manage it. Then maybe fiddle with the server.xml to get it on port 80, then mebbe you wanna put Artifactory in the ROOT context b/c you wanna be able to just browse the machine with a simple URL. Now why were we configuring Tomcat again? Oh yeah, the Artifactory thing that will eventually hold the extra bundle that the dumb rapc compiler depends on… You know what? Keep it simple. Copy/paste the repository folder from the Groovy svn location over top of your repository under ~/.m2. (Be careful on OSX because this is a replace copy instead of an append copy. Mac users should just drag the net folder from within the repository folder into their ~/.m2/repository). From there you should be able to use Maven to compile cod files from Java source. If everything works well enough, you should also be able to upload to an Antenna OTA server hosted in the clouds and then install to your device. Unfortunately the USB loader doesn’t quite work under OSX so unless you have parallels installed (in which case all the OSX specifics is moot) you’ll need to do it this way.

The Blackberry plugin supports only Blackberry OS 4.3.0 and higher. While it will generate cods that run on earlier revisions of the OS you will be subject to the all too painful verification error. I was in the middle of making it compatible with earlier revisions when I hit a few snags, particularly with the rapc tools. To be perfectly honest I STRONGLY reccommend a different approach if you want to build for Blackberry OS < 4.3.0.

These tools are sitting on the Groovy Subversion repository. You DO NOT NEED TO INSTALL GROOVY. You also do not even need to download/install the JDE. The only tool you need to use are the tools and compile to rapc files is Maven. Download/install Maven, check out from the subversion link, move the repository from the checked out folder into your $HOME/.m2 folder, and run “mvn install” in each folder then you’re all set! If there are any Maven/Groovy people out there that wish to help me build these tools out feel free to jump in.

Compile And Sign Blackberry apps on a Mac With Maven!

It’s Friday night and I finally found the answer to the last part of my SignatureTool.jar problem. See this post here that I will shamelessly inline for the fear of losing it to a random blog crash or deletion. The wonderful developers at Rim have never developed on Linux or Mac before. So they use backslashes in their path references! In short the post to download the ClassEditor software to poke around and change the values in the constant pool. (Get ClassEditor here then continue with the rest of the instructions.)

extract it, and run it with the command:
java -jar ce.jar

Open two class files extracted earlier: q.class and ad.class. ClassEditor will look something like this:
ClassEditor with q.class and ad.class

Start with q.class and select the Constant Pool tab. In this file we need to change string constants containing just a single backslash character. There are actually two constants in the pool but the first is just a reference to the second. The string we want is at index 223.
String constant at index 223

By default ClassEditor starts in read only mode so click the bright green Modify Mode(Off) button in the top right. The fields in the details area are now editable. Simply change the forward slash to a backslash and click Modify. Click save and that’s it for q.class!
String constant 223 modified

Select ad.class on left and locate constant 117, again in the Constant Pool tab.
String constant at index 117

Change the value from \sigtool.set to /sigtool.set and click Modify. Click save and that’s it for ad.class.
String constant 117 modified
Repack SignatureTool.jar and test

To repack SignatureTool.jar just cd to the temporary directory where you extracted the jar and rejar the class files
cd ~/lib/RIM43/bin/tmp
jar -cmf META-INF/MANIFEST.MF ../SignatureTool.jar *

Go up one directory and remove the temp directory
cd ..
rm -rf tmp

To test that everything worked, just run the command
java -jar SignatureTool.jar

If should prompt you to locate a cod file. Just cancel this and click the Properties button in the main signature tool window. If you see a list of Registered Signers it worked!

I followed the above with my copy of the SignatureTool.jar from the 4.2.x JDE and it worked flawlessly. After patching the SignatureTool.jar I repackaged it with the signature.csk signature.db and signatuer.set files and deployed it to our internal repo. The plugin I was working on now works without problems. I wanna stay up and work on this a little longer. I think I’ll put this post up on Monday.