Running a Gradle Build in Bamboo

Gradle is an excellent build tool for your projects. I’m really enjoying using it for my new projects, and I love having a full scripting language (Groovy) to write my builds in.

The one issue I had was integrating gradle into my continuous integration tool. I’m using the hosted Atlassian suite, so my continuous integration environment is Bamboo. However, Bamboo doesn’t natively support gradle.

Luckily, gradle has a great feature which allows you to run gradle builds on machines without gradle installed: gradlew. And, Bamboo has a feature run any script you like for builds. Below are instructions on how to configure a Bamboo build to run gradlew.

Steps to Create a Gradle Bamboo Build

Create gradle wrapper task in your gradle build file

task createWrapper(type: Wrapper) {
    gradleVersion: '1.0-milestone-3'
}

Run the task using gradle to create the gradlew scripts and download the jars
```
gradle createWrapper
```
Check in the gradlew scripts (gradlew and gradlew.bat) and the gradle directory (/gradle) to your version control system.
Create a new build plan in Bamboo for you project
Use your normal configuration for Plan Details and Source Repository
Update the Builder Section using the following values (make sure to set your working sub directory properly or gradlew will not fine your build.gradle)
```
Builder: Script
Script: ./gradlew
Argument: build
Working Sub Directory: <your project directory>
```
Setup your test reports directory in the “Where should Bamboo look for the test result files?” section
```
The build will produce test results: checked
Specify custom results directories: **/test-results/*.xml
```
Finish the rest of the build plan in Bamboo like you normally would

Run the build and you should see the gradlew loading in the log file. In the log you will see something similar to the following:

Downloading http://repo.gradle.org/gradle/distributions/gradle-1.0-milestone-3-bin.zip
Unzipping /home/bamboo/.gradle/wrapper/dists/gradle-1.0-milestone-3-bin.zip to /home/bamboo/.gradle/wrapper/dists
Set executable permissions for: /home/bamboo/.gradle/wrapper/dists/gradle-1.0-milestone-3/bin/gradle
:compileJava
Download http://repo1.maven.org/maven2/org/springframework/spring-webmvc/3.0.5.RELEASE/spring-webmvc-3.0.5.RELEASE.pom
Download http://repo1.maven.org/maven2/org/springframework/spring-parent/3.0.5.RELEASE/spring-parent-3.0.5.RELEASE.pom
Download http://repo1.maven.org/maven2/org/springframework/spring-asm/3.0.5.RELEASE/spring-asm-3.0.5.RELEASE.pom
.
.
.

You should also see that all your unit tests have run in the log and be able to see the results in the Test tab of the Bamboo Plan run.

Congratulations, you now have Bamboo set up to run your gradle builds.

Setting Up an Automated Test Using OS X’s Instruments Tool

Steps to Create a New Automation Test

First, create a test script to start with and save it to the file system. Here’s a very small example of what the test script will look like. Feel free to start with this:

var target = UIATarget.localTarget();
var view = target.frontMostApp().mainWindow();
var textfields = view.textFields();
if (textfields.length != 1) 
{
    UIALogger.logFail("Wrong number of text fields "
        +textfields.length);
} 
else 
{
    UIALogger.logPass("Right number of text fields");
}

Next use the Instruments Application to run the script by following these steps: 1. Open Instruments Application * Click on the Automation icon and hit the Choose button * Click on the Choose Target button in the top left of the screen * Select Choose Target 1. Either choose a target listed or click Choose Target … to open a finder view * If you need to find the target, look in your build folder of your XCode project. * Choose the file named YourAppName.app * Find the Script tab in the left pane * Click on Choose Script * Next Click on the Record button on the top of the Instruments application

Once you click on record, the Instruments application will open up the iphone simulator or device (depending on the target you selected) and run your test script against your app.

One additional tip, if you’re trying to figure out what elements are available to you in the current node of your app’s node tree, uses this command view.logElementTree();. This is really helpful to see which buttons, text fields, etc. you can access.

HTML 5 <video>

h.264 v. WebM

Well, the next major battle ground has been set in the war for the internet. Oh, sorry, I’m supposed to inject more civility in my discourse. The next big internet debate is the openness of Google’s WebM video codec versus Apple and Microsoft’s closed h.264 codec.

Is it really just that simple?

Of course not. The issue is a quite a bit more complicated than just open versus closed. Even if you leave out a discussion of the quality of the video codecs, the issue is still thorny.

Basically, I think it breaks down like this: The W3C will not endorse a standard that requires any licensing fees like h.264 (regardless if it’s free sometimes, it still requires licensing fees for some users including browser makers). And, the Mozilla foundation and now Google Chrome browser are are refusing to support any video codec that is not licensing free. However, some browser makers (notably Apple and Microsoft) do not want to use a video codec that is wholly controlled by one entity and not an open standard. Google’s WebM may be open source and Google may have guaranteed no licensing fees for the patents involved in WebM; but, it is NOT an open standard. There is no recognized standards body that has accepted WebM as a standard. As such, any browser maker that includes WebM would have depend on Google not changing the WebM specification in a way that breaks their implementation.

So, who’s right?

I think nobody. The best solution would be to have a licensing fee free video codec that is an approved open standard. Short of that happening, it would be nice to see Google propose WebM as an open standard to a standards body and relinquish control over it. And, the h.264 consortium could guarantee no licensing fees for anyone for using the codec. I doubt either of these will happen, unfortunately.

What happens next?

I think, unfortunately this will prompt content producers to use more Flash. If you’re a content producer, you have a choice: re-encode all your video (that you recently converted to h.264 to support the iOS devices) with WebM and keep both h.264 and WebM versions hosted on your servers. Or, wrap the current h.264 version with a Flash wrapper and call it a day. Those browsers that support h.264 will get the h.264 via the html5 video tag and those that don’t will deliver the content via Flash. This situation is not good. Having a standard <video> tag in html5 is really useful. This should allow web developers to easily integrate video into sites. But, when browser makers can’t agree on a codec, this tag loses it’s usefulness.

I’d like to see Google go back to supporting the h.264 codec as well as WebM. I’d also like to see the h.264 consortium give away a free and perpetual license to any browser maker that gives away their browser for free. This way, browser makers can support the codec without having to pay anything. Apple and Microsoft should also support WebM in their browsers as well. Then, let the best codec win. The content producers can then choose which codec to support (which is really where the decision should be made) based on quality of the codec, tool support, licensing fees, etc. And, as an added bonus, less Flash usage!

Web Apps for Blackberry

I’ve recently had the (mis)fortune to work on a mobile application which tried to support Blackberry versions lower than 4.6. This is not fun!

Blackberry browsers prior to 4.6 really do not support web applications. They may render static html alright, but do not try to create an interactive application utilizing JavaScript and CSS.

BlackBerry Device Software 6.0

This browser is leaps and bounds better than the previous versions. It is based on WebKit which makes it’s HTML, CSS, and JavaScript support far superior to the prior generations of Blackberry browsers.

BlackBerry Device Software 5.0

Blackberry 5.0 seems to work reasonably well. I did experience some issues, but there were usually alternative ways to structure the JavaScript to solve them.

BlackBerry Device Software 4.6-5.0

Blackberry 4.6 and higher is definitely better than 4.5 and under. For instance, most of my JavaScript worked in 4.6 except for JQuery validation. But, it’s still not great.

BlackBerry Device Software 4.5 and Under

Blackberry 4.5 and under should not even be considered a web browser. Here is what Blackberry says: “Browser supports JavaScript 1.3, subsets of JavaScript 1.4 and JavaScript 1.5, and the ECMA-262 ECMAScript™ Language Specification.” 1

Really, a subset of multiple versions of JavaScript?? That’s awesome; I’m sure you’ll tell us what that subset is, right? Oh, no, you don’t? Well, that’s not very friendly.

Seriously, I haven’t found where Blackberry specifies what is supported. That makes it fun to try and determine what will work. And, if you’re curious about the support for CSS, don’t worry: it’s just as bad. 2

Final Thoughts

Basically, if you’re writing a mobile web application and your client wants to support Blackberry 4.5, follow Nancy Reagan’s advice and just say no. If you need to support 4.6, make sure you test all of your JavaScript really well on a Blackberry running 4.6 or in the emulator.

Should MS buy Nokia? »

Here’s an interesting discussion of Microsoft buying RIM or Nokia. The author makes a convincing argument about Nokia being a better target. I agree; Microsoft has the mobile OS (Windows Phone 7 looks to be better than Symbian and who knows if/when Meego will be the smartphone platform for Nokia) and Nokia has the distribution channels. I doubt this will happen, but it would make the mobile space quite interesting.

HowTo Setup MarsEdit to use Markdown on Tumblr

It took me a few minutes to get MarsEdit, Tumblr and Markdown all playing well together. Since, I didn’t come across a concise version of setting these three tools up I’m posting the configuration that worked for me. Hopefully this will work for you as well.

Tumblr

Change preference (www.tumblr.com/preferences) “Edit posts using” to Markdown

MarsEdit

Set Default Editor Content to HTML Text (MarsEdit->Preferences->Editing
Set Preview Text Filter and Server Text Filter to Markdown (Blog->Edit Settings …->Editing)

After making these changes, you should be able to begin posting Markdown posts to your Tumblr blog via MarsEdit. One hint: if the preview in MarsEdit is showing the markup instead of the rendering, something is probably not working. Make sure you’ve set the preview to use Markdown and make sure Tumblr is setup to use Markdown as documented above.

I haven’t used MarsEdit that extensively, but so far I really like the ability to create offline posts and just publish when I’m ready. I think this workflow will work well.