[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.
DANGER!!!
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.
Can't see nothing but the source code 
I understand your pain playing with a Maven Repo Manager for yourself 🙂
Personally I just create a zip of the files with the maven repo directory tree that I put on Sourceforge for user to download. So, it can be unzip directly under .m2/repository or if you have Artifactory for everyone in your team use the “deploy zip” feature.
The SF projects are:
– maven anno mojo: Use Java 5 annotation instead of XDoclet for maven plugins.
– Jade plugins: A bunch of maven pugins like a native C/C++ plugin.
Yes Maven repo muckery can be painful but in this case I believe the pain comes from rapc and it’s absurd dependencies on everything from a dated javac to a custom preverify to an operating system. To think this tool was actually written in Java. FWIW, I absolutely love Artifactory. I almost switched to the other artifact manager on two occasions but I’m glad I stayed.
Hi Can u explain in simple terms what should be done to enable Blackberry JDE or Eclipse plug-in to work in Mac OS. Thank you.
Hi,
Could you send me a simple project
that demonstrates the usage of your plugin ?
I have installed it but it fails, it can’t the jad file.
Thanks
Hi there,
I’ve built your blackberry-maven-plugin successfully. However, I don’t know how to use this plugin in other maven projects, could you briefly show me how to use it please?
Thanks a lot! 🙂
I just realized how important documentation is when you do an open source project. I’m in the same boat as you. I’ve rebuilt the plug in after many years and forgot how to use it. I believe there’s an additional dependency on the RAPC compiler. I believe you have to package this along with the SignatureTool.jar and one other thing. It’s just past my lunch break now so I’ll have to revisit the idea tonight and see if I can make heads/tails.
Thanks, Cliff.
I’m really interested in this maven plugin but the first thing is to get it working for me first…. hope you can give a helping hand on this. 🙂
When i use the plugin, it says:
[ERROR] Failed to execute goal com.mapquest.mojo:blackberry-maven-plugin:1.1-SNAPSHOT:compile (default) on project TestMaven: Execution default of goal com.mapquest.mojo:blackberry-maven-plugin:1.1-SNAPSHOT:compile failed: Unable to load the mojo ‘compile’ in the plugin ‘com.mapquest.mojo:blackberry-maven-plugin:1.1-SNAPSHOT’. A required class is missing: org/codehaus/groovy/runtime/callsite/CallSiteArray
Do you know what’s going on?
Much apologies David, work keeps getting in the way! At any rate I’ve finally overcome my inertia and managed to get a simple J2ME project to compile with the plugin. You should only need to use a plugin declaration like the following in your pom:
<plugin> <artifactId>blackberry-maven-plugin</artifactId> <groupId>com.mapquest.mojo</groupId> <version>1.1-SNAPSHOT</version> <executions> <execution> <goals><goal>compile</goal></goals> <configuration> <sourceDirs> <sourceDir>${project.basedir}/src/main/java</sourceDir> </sourceDirs> <resourceDirs> <resourceDir>${project.basedir}/src/main/resources</resourceDir> </resourceDirs> <jadFile>${project.build.directory}/${project.build.finalName}-me.jad</jadFile> <sign>true</sign> <signaturePwd>mqm0b1le</signaturePwd> <midletName>${build.finalName}</midletName> <outputDir>${project.build.directory}/rapc</outputDir> </configuration> </execution> </executions> <dependencies> <dependency> <groupId>net.rim</groupId> <artifactId>rapc-compile-tools</artifactId> <version>4.2.0</version> </dependency> </dependencies> </plugin>This declaration implies the dependency of rapc-compile-tools, which is an additional repo upload that you’ll have to prepare manually. It needs at least a copy of rapc.jar and the net_rim_api.jar to function properly. I cannot distribute that bundle without breaching whatever legalize RIM happens to place in the web form you click thru to download the bundle. I haven’t even read the legalize but I know that distributing their tools would be a breach of contract. The bundle is merely a zip file with the following layout:
-rw-r–r– 1 cliftoncraig07 cliftoncraig07 116406 Mar 15 10:44 SignatureTool.jar
-rw-r–r– 1 cliftoncraig07 cliftoncraig07 6261097 Mar 15 10:43 net_rim_api.jar
-rw-r–r– 1 cliftoncraig07 cliftoncraig07 4 Mar 15 10:40 preverify.exe
-rw-r–r– 1 cliftoncraig07 cliftoncraig07 4 Mar 15 10:40 rapc.exe
-rw-r–r– 1 cliftoncraig07 cliftoncraig07 409622 Mar 15 10:43 rapc.jar
-rw-r–r– 1 cliftoncraig07 cliftoncraig07 162 Mar 15 10:44 sigtool.csk
-rw-r–r– 1 cliftoncraig07 cliftoncraig07 285 Mar 15 10:44 sigtool.db
-rw-r–r– 1 cliftoncraig07 cliftoncraig07 176 Mar 15 10:44 sigtool.set
Optional files are the signature files and are only required if you wish to sign the app. The sigtool.csk, sigtool.db and sigtool.set are the things that are installed next to the net_rim_api.jar after you go through the registration process and finally obtain a certificate to sign applications. I have both the exe and the raw jar packaged because I believe I was doing some extra work to make this work on Windows with OS prior to 4.2.2 but I don’t recall how far I got. I’m not sure why you’re getting the error you’re getting but I believe that by creating and installing the rapc-compile-tools bundle you’re problems should go away. My plugin works by expanding this bundle to a temp directory as its found in the plugin’s classpath. It then issues cmd line commands to invoke the compiler using properties set in the pom as parameters. I just tried this after checking out my source from the groovy repo (I upped the version locally to be sure there would be no conflict with a checkout from our internal repo) and it works. I definitely intend to get another post soon with better documentation. It would also be nice to have a rapc-compile-tools bundle creator but I can’t make any big promises!
Wow, I left out another detail! All of the above files must be tucked inside a “/Blackberry-utils/” folder in the rapc-compile-tools dependency. I’m posting a followup to explain but if you look in the plugin source (I know, eew yuky!) you’ll see where things get expanded. Your error likely comes from the static block
static { tmp = new File(System.properties["java.io.tmpdir"], ".mqrimtools") if(!tmp.exists()) tmp.mkdirs(); ["rapc.jar", "net_rim_api.jar", "SignatureTool.jar", "sigtool.csk", "sigtool.db", "sigtool.set"].each { file -> def jar = Compile.class.classLoader.getResourceAsStream("/Blackberry-utils/${file}") def expandedFile = new File(tmp,file) println("Expanding ${file} to ${tmp}") new FileOutputStream(expandedFile) << jar println("${file} expanded to ${tmp}/${file}") } }That block is used to setup an environment where it can find the RAPC compiler and signature files to do the final signing.
Hi there,
Does this plugin support dependencies? i.e. we have a few other Blackberry projects that build to jars/cods – does your plugin support writing these dependencies to the main JAD and compiling them as references?
If I remember correctly it takes an existing Jad file, given under the configuration section, to pass to rapc. (It’s embarrassing that I can’t remember how a plugin that I just used yesterday is supposed to work!) You can use Ant or some other Maven plugin to generate a Jad listing the dependencies. I am seriously not happy with the shape of the plugin because it was built to fit the shape of our mobile mobile project. Now that I’ve finally figured out how RAPC works I’d like to revisit. I’d welcome any/all help ideas and suggestions.
Do you mean that i need to put an existing JAD file under the “target” folder or else the mojo just can’t run? It sounds a bit weird though that i need to have the JAD file ready before compiling the project….
Yes, weird but not really. Most J2ME template projects generate a Jad for you in the source directory somewhere. This affords you the opportunity to preprocess the jad prior to passing it to the compiler. In other words you could work from a Jad template under your source folder and have it copied/filtered to the output folder replacing property refs (${var} patterns) with build-time values. (device specific properties become valuable for building to different blackberry phones like touch vs. non-touch) This is typically done in the preprocess stage. Then when the compiler goal runs it picks up the processed jad and uses it to build the cod. It might make sense to create an additional goal in the mojo (or in a separate mojo) to generate the Jad using values passed from the pom in the goal’s configuration. Still that would make it even more necessary for the compiler to use the JAD from the target folder. Actually if you notice in my snippet the JAD file can be located anywhere as it is a configuration parameter passed to the mojo. It just worked easier for my project to find it under the target folder.
Hello colleagues, its wonderful post about teachingand fully defined, keep it up all the time.