GMaven for Blackberry development on a Mac?


Ok, it’s been a while but I finally posted the code for GMaven-Blackberry in another blog post.

I’ve gone clear outta my mind. I’m thinking let’s build a blackberry native app on the Mac. Sure! Why not? I mean there’s only the long-standing platform incompatibilities between J2ME and OS X, the windows-oriented nature of Blackberry tools, the mismatch of typical J2ME project structure and Maven project structure and looming deadlines to worry about. And while I’m at it, throw Groovy into the mix, because everybody knows that Groovy has everything to do with writing embedded apps right?

This week I’ve bounced between a Gant build, a legacy Ant build, our multi-module maven JEE project, and brand new GMaven plugin projects. Let’s just say I’m becoming very familiar with the build process in general. Project structure is important. The build system is critical. It is at the root of every successful and failed project in history. Many problems, and resolutions to problems stem from the build/deployment system in place on a given project. It makes sense that as a developer you pay close attention to what’s involved in the building and deployment of your software. Yet soooo many people fail to understand the variables involved in the build tool chain. Many a problem can be tracked to system incompatibilities resulting from version mis-match and/or conflicts. Something as simple as a micro point release difference in your web container or JDK can cause an app to behave wildly different. (Today I tracked a bug down to Tomcat 5.0.28 on a dev box where version 5.5.25 is running in production.) The version numbers of your build tool chain is often the last place developers look when researching a problem. It is the first thing I look for when trying to isolate an issue. I digress.

With all the build tools ranging from Ant to GAnt to Maven to Gradle… (BuildR anybody?) it’s easy to get overwhelmed. I had a buddy remind me how important it is to refrain from going overboard in leading edge-multi-faceted-combined technologies. Stick with proven products yet always look for the next thing. That’s how I feel about Maven. There are alternatives some have better features. However Maven is mature and ubiquitous. I don’t have to pull in yet another runtime to build my project. I don’t need to learn yet another platform. It does its job and does it well. So well that I try to use it for all of my Java work, bringing me to my point. J2ME Blackberry development can be done with Maven. It can be done on a Mac. And at the end of my ordeal it should be painless to do on a Mac.

So why Maven? Why not Ant? The app I’m working on includes several JEE complimentary pieces and I’m sorry but I would rather not touch Ant on a web app project. No way, no how. Furthermore with JEE making up over half of the codebase Maven is the perfect solution for managing the project. We currently have it in use and we have a wrappering pom around the Ant build we use for our J2ME client. That wrapper has been a source of utter pain. So I’ve been looking to figure this out for the longest.

What does Groovy have to do with it? Well I have the Pyx4ME J2ME plugin for Maven working pretty well but there are some obvious holes. First off is a decent deployment mechanism. I need to tie deployment into the modified Antenna OTA servlet we have. Secondly there is no support for Blackberry in the plugin so somebody needs to add it. I started to write a plugin and I just knew I wouldn’t want to be bothered writing it in Java. A couple of minutes after I finished bouncing between 20 different reference articles, APIs, and PDFs and I had the beginnings of the RIM plugin for Maven complete with OS X compatibility. It’s not totally finished yet. I still have issues running the jar signing tool on the Mac. (It should run fine on Windows, and possibly Linux.) But it runs the compiler. I’ve generated a .cod file in the target folder of a prototype project. Interesting stuff indeed.

If that’s not enough, I’ve also managed to launch GAnt from within Maven! Why would anybody want to do this? Maven is become widespread like Ant. If you or your team already use Maven but you want to toy with Something else like Gant you would have immediate access. You don’t need to open your browser, don’t launch Safari, just run Gant:

mvn gant:run

That’s it! And that’s perfect for my current situation where I’m trying to spread Gant across my team. The same applies for Groovy. Don’t go to the codehaus site, just run it!

mvn groovy:console

There’s something to be said about the convenience of a one stop shop. That’s my thing for now. Stop back because I’m gonna continue to post updates on not only Groovy, but Blackberry, GAnt, Maven, maybe even Gradle if I get that far. Holla!

I got it!


I just ran the Blackberry compiler from Maven… on my Mac. Two cans of Pabst Ice and one Mike’s hard cranberry lemonade into my dev cycle and I finally see a “.cod” file show from a pyx4Me project! It’s in the wrong folder, project root vs. projectroot/target but I can live with that for now. Anyone know a groovy way to set the working directory from a command string run by the overloaded String.execute() method? I don’t wanna call out to Runtime.exec and I don’t wanna write a bunch of platform checks in my plugin. Right now I’m one too many drinks swallowed to know whether or not String.execute() implies platform. In other words I don’t know if I need to code a prefixing “cmd /c ” on my string and check for Windows before calling String.execute(). I’m not happy with the impl because there were a few things I wanted to do better. Right now I’m spawning a java process because the GMaven plugin doesn’t set the rootLoader, which means I can’t dynamically append to my classpath. I’ll either have to set the rapc.jar as a dependency or figure something else out. I’m just glad I got this far! More updates later…

Build Native Blackberry apps natively on a Mac… using Maven!


Click here for the Maven Blackberry code behind this post.

Aight, I can’t help it! I’ve been itching to get this done for sooo long. If you’re into Blackberry development then you’ll understand just how absurd the above title sounds. Let me just throw intelliJ Idea into the mix as well then you’ll begin to see the big picture. Starting to do J2ME development, an experienced Java guy like myself has naturally gravitated towards a certain set of tools. Maven2 is hands down the only acceptable build system for a Java project, while Idea beats the pants off of Eclipse, and Windows boxes…? Forget it! Java runs practically double speed on a *Nix OS plus with the flash of OS X there’s no question as to what boots on a typical knowledgeable hard working Java developer’s box. All of these tools work well, and most of them work well together. BUT… BUT!!! Doing J2ME implies Windows and Ant all around so there’s gonna be either a divorcing of the toolchain or a boatload of integration issues. This weekend I fought through the biggest of the integration issues. And this morning I finally managed to build a Blackberry .cod deployable program… completely without Windows… using a Maven2 pom… natively on my Mac! I’ve been updating my blog incrementally with all of the individual pieces so I won’t go into too much detail here. At a high level I’ll explain the tools involved.

  • One Apple Macintosh (iBook, MacPro, MacbookPro, MacAir, whatever…)
  • One Blackberry (Preferably not Verizon because I don’t think they support J2ME)
  • One Windows install (I know, but this is only to extract the Blackberry tools! You can throw the whole thing away once you got the goods out of the JDE downloads. If you have a buddy that already has the JDE just steal it from him and skip this piece all together.)
  • One install of the Blackberry Java Development Environment (JDE).
  • One bottle of scotch (or wine) for to celebrate with.
  • One install of Maven2
  • Two tablets of asprin (to handle the hangover after you’ve spent the entire rest of the day celebrating with scotch or wine.)

I think that’s everything in the ingredients list. I’ll post back later with the recipe as time allows.

Run Progaurd Preverify os OSX?


Last night I went heads down researching and trying to figure out how to get passed the infamous preverify hurdle when building J2ME apps on OS X. I’m happy to report that I’m an idiot. I went through a boatload of trouble finding and almost attempting to fix a bug in the Antenna preverify task as it is slightly broken on OS X. I emailed everyone I could think of who had anything to do with Antenna, the Maven2-J2ME-plugin, and OS X. I submitted to blog posts along the way as I worked. Just moments ago I found what looks like a much more simple fix. The Pyx4ME project includes support for Progaurd which now includes a preverifier! I completely overlooked this option as I waded through mounds of documentation al from different sources regarding the best way to get past preverification on OS X.

I just ran a build with the Progaurd preverify option and it succeeded! I haven’t tried to run it or anything… that step comes next. I’m all too excited to see something actually run all the way through on my Mac.

I must admit that I’m slightly hesitant to take this approach due to the frailties our team has found with build time tools for J2ME. I’m speaking about issues with different JVMs, different obfuscators, too many obfuscators, lack of obfuscators, preverify configuration, application signing methodologies, and every other flaming hoop you have to leap through to get a decent build for a single device. I’d go into detail but I wanna keep plugging away to see how far my insanity can carry me.

Run WTK preverify on OSX!


In other breaking news I found a possible way to do true cross platform WTK development. If you’re not familiar OS X is the one platform where you really can’t do JavaME unless you’re really really savvy! The missing too is preverify. (An intel Mac compatible version can be found deep in the bowels of the PhoneME source download.) There’s the ol’ MPowerplayer preverify tool but that’s a little dated and out of synch with the WTK preverify tool. As a result you’ll find tools such as the EclipseME and Pyx4ME plugins won’t work with it. (Actually I believe EclipseME has Mpowerplayer support but I haven’t tried it.) I’m gonna keep this short so I can work on it. There’s this cat that’s blogging about doing cross platform JavaME development and I’m reading the blog now. On the blog he explains that the preverify tool in the PhoneME MR2 download under phoneme_feature/cldc/build/share/bin/darwin_powerpc/ will run on an Intel Mac. I just tried it on my 2.4Ghz MacPro running Leopard and I was able to bring up the help text from the command line. I’m loosely following his write up and a few other tutorials and links in an attempt to create a deployable Blackberry J2ME project using Maven on my Mac. We’ll see how far I get.

Run The Blackberry Compiler on Linux


Run rapc on Linux? Rapc for Mac? BSD and rapc?

Seriously, is this possible? I’ve been wondering for a while how feasible it would be to do J2ME development full time on a Mac or Linux machine and I dunno… it sounds reasonable at times and far fetched at other times. Today I found this gem. A guy supposedly got rapc, the Blackberry compiler, to work on a Linux machine. I’ve personally managed to sign Blackberry apps without requiring a full JDE install so maybe this is the other half of what I’ve been looking for? Here’s a shameless copy from the forum, in case it ever get deleted or lost:

1. Compile normal midp-2.0 midlet with J2ME SDK from Sun
2. set up $WTK_HOME to point to your J2ME install, $RIM to point to
your JDE/MDS/classpath, and $APPNAME to your app name
4. cd to $WTK_HOME/apps/$APPNAME
3. run
PATH=$WTK_HOME/bin:$PATH \
java -jar $RIM/rapc.jar import=$RIM/net_rim_api.jar \
codename=$APPNAME -midlet jad=bin/$APPNAME.jad bin/$APPNAME.jar

Your .cod file will end up in current dir. bin/$APPNAME.jad will be modified to contain all
BB-specific info.

I’m looking to do something with this knowledge. I’ll post back if I ever come up with something.