14
Jul

How to build a Flex Mobile App with Maven

Building applications that run on mobile is today’s trend. Everybody is thinking mobile and social and cloud.

To build a Flex application for Mobile is very easy, provided you use Flash Builder. When it comes to automating that build, things are not as easy. Because recently I’ve managed to overcome the obstacles that were preventing me to build a running Flex 4.5 app for mobile, I want to share the build.

I’ve taken the initial build from this thread. Marvin Froeder ( a.k.a VELO ) has been doing some hard work recently, creating the Enterprise version of Flex Mojos. This version seems pretty promising. I’m looking forward for its release. When you’re testing the build, make sure you register during the build, following the instructions. The process is fairly easy, but … rewarding. The maven build creates the final apk/air/exe/dmg…, which you can use to install the app on your device. It’s worth trying it.

To build the app, you need to execute

mvn3 clean install package

Prior to the build, you need to make sure you have Maven 3 installed, with the following environment variable:

MAVEN_OPTS="-Xmx1024m -Xms128m -XX:+DisableAttachMechanism"

Also, you need to have the mobile theme installed in a repository. As of today, the flex mojos repository doesn’t contain this theme, so you need to install it manually.

When the build ends, connect your device to the computer and execute:

adb install -r ./target/mobile-1.0-SNAPSHOT.apk

Then, go to your device and open “main” application.

If you see the following screen, it means that the application got compiled successfully.

Maven Mobile Screenshot

Screenshot showing the app built with Maven

30
Jan

Jenkins (ex-Hudson) plugin to capture Flash Logs during build

Lately I’ve been working on a plugin for Hudson / Jenkins that captures Adobe Flash Player logs during a build, making them available as build artifacts.

This plugin is useful when you want to debug Unit Test or Automated Tests which are failing in the CI machine.

For me information you can check http://wiki.hudson-ci.org/display/HUDSON/FlashLog+Plugin

05
Jan

Solving “file already exists” Maven/SVN Problem

Problem
Today I’ve been trying to perform a maven release on a project hosted on google-code and I’ve hit a major roadblock.

The build was failing due to a SVN error occurring when maven was committing into SVN, into the tags folder, the current version of the project:

[INFO] Unable to tag SCM
Provider message:
The svn tag command failed.
Command output:
svn: Commit failed (details follow):
svn: File '/svn/path/to/my/file/myclass.java' already exists

Solution
The solution is rather a workaround, than a solution: force a svn update before committing the code into SVN repository.
Searching to see if other people have had a similar problem I discovered this bug, and in one of the comments of the bug I saw the workaround:

# mvn release:prepare
== fails ==
# svn up -r head
# mvn release:prepare -Dresume

As you can see, you are being suggested to do a svn update after the build fails and resume the release process from that point.

I tested this workaround, and luckily for me, it worked. Going further, I thought that’s great, but how can I deal with these extra steps on my continuous integration machine ? I didn’t want to create a special job just to do the release of my library, so I started to see if I can integrate this workaround into a single maven command line.

Looking into the Maven Release Plugin, I discovered the preparationGoals property. As the documentation specifies, it defines which “goals to run as part of the preparation step, after transformation but before committing..

Into these preparation goals I executed a shell command, using Maven Exec Plugin.

mvn -e release:clean release:prepare release:perform \
  -DpreparationGoals="clean install exec:exec" \
  -Darguments="-Dexec.executable=svn -Dexec.args=up"

This single command did in the end the same thing. Forced a svn update before committing the code into SVN.

Apparently this bug occurs only for SVN versions up to 1.6.4. In SVN version 1.6.5 this shouldn’t be a problem anymore. Too bad that Google Code uses older versions of SVN.