Mavenizing a Flex build
In the last week the release 1.0 platform release of scoyo came close and we were tying up some loose ends. One of these ends was the integration of the scoyo Flash/Flex portal build process into the platform build process.
The platform build process is realized with Apache Maven, which is, in humble my opinion, still the first choice for Java based software projects, but integrating other project types into maven is a kind of challenging due to the nature of Maven. You may summarize this in: If you do it the maven way it’s very easy, if you don’t it is up to you …
Luckily there was already an existing build with Ant and a dysfunctional Maven variant with the Maven Flex-mojos plugin. So it stated my journey to insanity an back …
In the last week the release 1.0 platform release of scoyo came close and we were tying up some loose ends. One of these ends was the integration of the scoyo Flash/Flex portal build process into the platform build process.
The platform build process is realized with Apache Maven, which is, in humble my opinion, still the first choice for Java based software projects, but integrating other project types into maven is a kind of challenging due to the nature of Maven. You may summarize this in: If you do it the maven way it’s very easy, if you don’t it is up to you …
Luckily there was already an existing build with Ant and a dysfunctional Maven variant with the Maven Flex-mojos plugin. So it stated my journey to insanity an back.
My first attempts started with reactivating the Flex-mojos maven build. I already had some experience with Flex-mojos when preparing the build for the jaev Flex example. This example Project for the jaev framework also uses the Flex-mojos maven plugin to create the example .swf and uses the infrastructure of maven to assemble the web application with the HTML and the BlazeDS services. Took me some time and a quite nice tutorial from Sébastien Arbogast but finally it worked!
So I thought I was prepared for the task and nothing could stop me. There is no law against being wrong, at least in Germany .
The main problems was finding all the required libraries in various maven repositories. Additionally there were some foul libraries. Some yahoo uploaded HTML files as .pom and .jar file in a repository. It took me quite a moment to realize this. Unfortunately the current Flex SDK 3.3 was not available at all in any maven repository. At least I did not find any.
So after wasting some hours I changed the strategy: My new Idea was to call the Flex Ant tasks provided by Adobe from the maven build using the maven-antrun-plugin. The antrun-plugin is quite nice if you have to perform some tasks not covered by maven. So you can execute some Ant tasks to enrich your build.
But things where going to be worse. A couple of very “unsatisfying” hours later I discovered a bug or incompatibility of the maven maven-antrun-plugin and the Adobe Ant tasks. So it was time to rethink my strategy again. Should I switch back to the Flex-mojo approach? I went for a minor adjustment first: Instead of using the the Ant tasks I went for the compilers (mxmlc for Flex applications and compc for Flex libraries) directly. Calling them with the Ant <exec /> task, which executes a command on the command line. Then use the maven-assembly-plugin to create a ZIP file of the compiled artifact and install/deploy it into the repository.
Let’s sum this up:
- start JVM and execute maven
- execute the maven-antrun-plugin to execute ant tasks
- use some Ant tasks to assemble the Flex build path (external and included libraries)
- use the Ant
<exec />task to execute the flex compiler (let’s share a secret: The Flex compilers are written in Java. Welcome back home - use the maven-assembly-plugin
- install the ZIP file into the local repository
- (optionally deploy the artifact into a remote repository)
to create a ZIP file
That does not sound like a simple build process. And let me amend something: If you a using shared libraries in the build (yepp we have a couple of them) you may add another step before invoking the maven-antrun plugin. You’ll have to use the maven dependency plugin to copy and uncompress the libraries from the local (remote) repository to your build environment, so they can be accessed/found by the build. You’ll imagine I was not satisfied at all with this build variant …
Again my old friend came along, the question:”What to do?”
The Flex-mojo approach obliged my to upload the whole Flex SDK into our local archiva installation which hosts out company maven repository. This includes the minimum 54 libraries supplied by the Flex SDK. Okay most of them are quite common, but when a new Flex SDK is released (which happens on a quite regular basis) you’ll have to recheck all dependencies. No thanks …
The maven/Ant/Flex compiler variant emerged as juggernaut with bad performance and a loads of catches. No improvement at all …
So I decided to take a closer look at the Flex-mojo plugin itself. Why do I need to have all this dependencies? The major advantages to the Flex-mojo plugin are the special packaging types swf and swc for Flash movies and libraries. Using this packaging types maven will use a special life cycle and offer the possibility to install/deploy the artifacts directly into the repository. To my relief only a quite simple XML file (a plexus component definition) was necessary to achieve this.
So desperate as I was, I decided to write a maven plugin on my own. I must confess it was not my first time. I already wrote a simple maven plugin for the SinnerSchrader commerce framework, a library developed by my former employer. I really do not like to reinvent software on my own. But I was curious and I want to give it a shot. My goal was to combine the two approaches I tried before and use the best of both. So the plugin should be able to manage the swc dependencies, the flex compiler configuration (via -load-config) and the direct deployment of swc and swf artifacts.
The approach was simple:
- check the maven dependencies for libraries to reference or to include
- check for a configured compiler configuration
- create the compiler command line and all options like
-load-config,-compile.debug,-compiler.include-librariesor-compiler.external-library-path, etc. - invoke the compiler via the
java.lang.ProcessBuilder - install the artifact into the local repository
It took me not an hour to build a working proof of concept and only approx. four more hours to mavenize almost the entire build. This was really fun after two days of trying and failing. There are still some minor adjustments to make on monday, but I am really looking forward to finish the build. And if all works out as I want, there might be a 15-20% speed improvements for a complete build. But this also reduces the necessity to perform complete builds, because some shared libraries are rarely changing at all, so we can deploy them into our company maven repository.
As I went to bed last night, I was wondering why the Flex-mojo approach failed and the home-grown maven plugin approach succeeded. Under the shower this morning it was quite obvious to me. The Flex-mojo plugin stores the whole Flex SDK in maven repositories, so you don’t even have to download the Flex SDK to compile your Flex application. My home-grown plugin needs the Flex SDK installed on the build computer and the FLEX_HOME environment variable set. But that is okay, because the maven-compiler-plugin does the same. It does not work without the JAVA_HOME set and it does not try to deploy the Java SDK into maven repositories. Maybe the Flex-mojo guys will also realize the difference. It seems to be a quite nice piece of software but with too much unnecessary complexity and very “clustered” documentation.
After tying up this loose end me and a very experienced Flex development colleague already discovered some further TODOs relating to the maven and Flex Builder integration. There is still lots of work to do, so I am exited. My new job is different as I expected but a am very confident that it will offer some exiting further challenges for me …
Getting closer to 1.0 New technical Infrastructure and design
