Quickstart flex development with this maven archetype

Have you considered starting some flex development, but haven´t found out where to start? Or are you already flex'ing but could use some easy way to quickstart new flex projects in java?

I have created a maven archetype called maven-archetype-flex and distributed it to ibiblio for all to use.
It will quickly get you up and running.

Here is how you do it:

1. Download flex sdk
Download the flex sdk from adobe, if you haven't got it already.

1b. Minor change to flex-config.xml
You have to uncomment the following in your flex-config.xml located in:

${flex.home}/frameworks/flex-config.xml

<local-fonts-snapshot>localFonts.ser<local-fonts-snapshot>

Otherwise the compiler will complain as Matt mentions in his comment.

2. Create flex project
Running the following maven command will create a flex project called my-flex having groupId my.group. Feel free you change these to what ever you like:

mvn archetype:create
-DarchetypeArtifactId=maven-archetype-flex
-DarchetypeVersion=1.0
-DarchetypeGroupId=dk.jacobve.maven.archetypes
-DgroupId=my.group
-DartifactId=my-flex
-DpackageName=

Note: it is important that you remember the -DpackageName= as the Main.mxml flex file in the archetype is to be kept in the root of your source dir and not in some subpackage.

3. Set flex.home property
In the newly created project pom.xml you should change the flex.home property to fit your flex.home path.

4. Build flex project
Now you are ready to build the flex project:

mvn install

Running this command inside your project will build the project and create a swf file in the target directory.

Viola! You have just created a simple flash application ready to use.

Where to go from here
To see the result of the work you can do one of the following things:

• Open the flash file with your favorite browser.
  
• Download the standalone player for your operating system ().
• Deploy the swf file to a webserver. Maybe you can get inspiration on how to do it from this maven flex template.
  

Flex maven template - getting started

In Per´s lession 1 of his flex development tutorial he showed us a build setup - it is a bit outdated by now as the israfil plugin moved to google code and the sateh repository doesn't exist anymore. It also only contained the flex module and no war sample showing how easy it is to deploy the flex application.

I took the liberty to create my own template consisting of a multimodule build:

• Flex module - looking prettymuch the same as Per´s.
• War module - depending on the flex module wrapping the swf file into a war ready to deploy.

I would have created a maven archetype, but considering mavens lack of support for archetypes containing multimodules I just created a zip.

I find the template useful when starting a flexproject from scratch and maybe you will too?

Download
Download the flex-template

For more information about the israfil plugin click here

Sharing flex code examples

Developing flash front ends with flex is really getting to me.
I don't have Flex Builder but find no problem with developing using another IDE combined with maven and the israfil mojo.

From time to time I blog about some nifty actionscript 3/flex code but I am missing a simple way to distribute the sourcecode.
Unfortunately my IDE - Intellij IDEA - doesn't contain a feature making it easy to distribute the flex sample code, neither have I found a maven plugin capable of packaging the sourcecode for distribution.

Adobe added the ViewSource capable of linking to some arbitrary URL where the source is located.

import com.adobe.viewsource.ViewSource;
...
ViewSource.addMeneuItem(this,"srcview/index.html");

But then again you have to have the source code distributed :-)

I am considering developing a maven plugin that can do the job, but it would be waste of time if a solution is somewhere "out there".

So please let me know!

Maven defaults is missing something

Mavens defined conventions for resources as follows:

• Java files in src/main/java
• All resources in src/main/resources
  

And on the surface it seems fine. Keep your java source and resources separated and clean.
But for some resources it makes sence to keep them "close" to the java class using it - say in the same package. I could do that by duplicating package structure in my resources directory, but that would be repeating myself and breaking the good old DRY principle. But furthermore and much more important I risk to miss the resource files when refactoring my build (renaming packages, moving classes).

So I always end up overwriting the resources definition in my pom.xml to something like this:

<build>
  <resources>
    <resource>
      <directory>${basedir}/src/main/resources</directory>
    </resource>
    <resource>
      <directory>${basedir}/src/main/java</directory>
    </resource>
  </resources>
</build>

I have been one of the defenders of mavens conventions, but this time it seems to be missing something.
Can anyone tell me why this isn't the default in maven?
I can't be the only one placing resources along side with my java files.

A badly packaged project will break builds!

I have stumpled across many comments on different blogs bashing maven for being a bad build tool. To me it seems that an era of "hate maven" is rising and many people seems to just blindfolded follow the horde of maven bashers.

It seems to me that people tend to forget what maven brings to a project.

• Convention above configuration.
• Dependency management.
• A bunch of default plugins ready to be used. (You can argue the quality of all opensource plugins, but I really think it is getting better)

A thing like dependency management is one of the greatest benefits. Luckily I have forgot the old days where precious time was spend looking for dependencies need by other dependencies.

Although maven provides many benefits I ran into one of the things that one could call a bad side effect of using maven and its transitive dependency management.

The springframework is distributed in two different ways.
As a single artifact containing the complete spring distribution and as a much more fine grained distribution where each artifact contains a logical spring module.
As it all seems fine and interface21 probably think they are pleasing the broader audience by providing the different distributions, it brings a bigger problem to the surface.

By providing the same code in different artifacts you introduces the risk of a project to unintentionally depend on the same software in different versions.

In my case just adding the acegi 1.0.4 to my maven pom.xml broke our build - and I did not even configure or use any of the acegi code!

Ofcourse I wasn't late to blame maven. As the problem showed up by just modifying my pom.xml the problem couldn't be blamed on anybody else but maven.

Some exercises with the -X option shed some light on my problem:
Acegi 1.0.4 depend on the fine grained distributions of spring 2.0.4 modules, but as it happens I already had a dependency to the full spring 2.0.5 artifact. Dependency resolution interprets the to versions of the same software as different artifacts - and if you stick strictly to the maven dependency resolution rules they sure are different!

A dependency is defined uniquely as follows:
<groupid><artifactId><version><package>

As the version changes, maven takes care of using the latest version. But with different artifactnames containing the same code, you are most likely leaving your users of your library with a classloading issue just around the corner.

Hence the cause of the problem was lying outside maven.

Now you would probably tell me that I should only use the fine grained spring dependencies - but I was probably lazy and sure others out there are lazy too.

My experience sums up to the following rules of thumb:

1. Apply DRY to your artifacts distribution.
   If you repeat yourself in your artifacts you introduce risks (not the same type of risk though) as if you repeat your code.
   
2. Choose your groupId wisely and do not change it again - ever.
   

After blaming Spring I can tell that Spring isn't the only one to break dependency rules of thumb.
Ehcache has changed its groupId between version 1.2.3 to 1.2.4 and bingo! You have to different artifacts from a dependency resolution point of view.

Conclusion
Even with the quirks I just described I still think maven dependency management it is fare better than the good old plain Ant days!

Hints
If you suspect that you have run the same problem as I did, I suggest you run maven with the -X option as it prints the complete dependency resolution tree. From there you can find what transitive dependencies to exclude.
If you prefer Ant you should take look at the dependency management tool Ivy, but that subject is worth its own blogpost...

Centralize surefire reports from multiple maven modules

For a long time I have been cursing the maven-site-plugin for not giving me the opportunity to assemble and centralize all surefire reports from my submodules.

One could argue (and I agree) that a benefit of using maven is that it urges you to split your code into logical reusable artifacts (submodules). But at the same time as you don't have the tool to combine reports from the submodules you could easily be loosing the big picture of any errors and failures in your testcases.

Up until now I have either ignored the fact that I couldn't get the big picture (yes, I'm ashamed :-) or implemented a solution using the maven-antrun-plugin and a simple Ant script.
But then my colleague Per showed me the fairly new dashboard-maven-plugin from codehaus and that does exactly what I have been missing for quite some time.

As they say: "The basic purpose of "Maven Dashboard Report Plugin" is to centralize and share all quality informations generated by other Maven report plugins..."

Finally, home grown Ant solutions seem to be history!

Still thinking on this project I worked on last year together with my good friend and colleague Claus, that could benefit from moving to the dashboard-plugin and throw away the ant solution we implemented.

Tip: How to depend on non maven artifacts in a maven build

Have you ever wanted to depend on some jar file that is not located in any public maven repository you probably ended up copying the dependency to your local repository and creating pom and md5 files by your self. Maybe you didn't even create the md5 files as it is not necessary and 'only' generates a warning in your maven build lifecycle.

Instead of doing all the hard work, you could use the install-file goal maven-install-plugin.

The install-file goal installs the artifact into your local repository. It can aslo create the nessesary pom.xml and checksum files.

A simple example of use:

$ mvn install:install-file -Dfile=pzfilereader-3.0.0.jar -DgroupId=net.sf.flatpack -DartifactId=pzfilereader -Dversion=3.0.0 -Dpackaging=jar -DgeneratePom=true -DcreateChecksum=true


Flex/flash could learn from Java and Maven

Yesterday I told my colleague how much I loved the tight integration between flex components and XML.
Pretty much any UI flex component can use a xml document as a dataprovider and you can dynamically use attributes or nodes in your component.
That really brings your application up to speed in a hurry.

Just as I had declared my affection for the integration I ran into a bug best demonstrated by this small example:

<?xml version="1.0"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" initialize="init()">
    <mx:Script>
        <![CDATA[
    import mx.controls.Alert;
    import mx.events.*;
    import flash.events.*;

    private var work:String = "<tmps><tmp att=\"abc\"><dummy/></tmp></tmps>";
    private var wontWork:String = "<tmps><tmp att=\"abc\" /></tmps>";

    private function init() : void {
        result.text = work;
    }

    private function clickHandler(event:ItemClickEvent):void {
        if (event.label == "OK") {
            result.text = work;
        } else {
            result.text = wontWork;
        }
    }

    private function printResult(event:MouseEvent):void {
            var list :XMLList = XML(result.text).tmp;
            Alert.show(list[0]); // should print first element in the list - the tmp element
    }
    ]]>
    </mx:Script>
    <mx:Panel title="Flex bug example" height="100%" width="100%">
        <mx:ButtonBar itemClick="clickHandler(event);">
            <mx:dataProvider>
                <mx:Array>
                    <mx:String>OK</mx:String>
                    <mx:String>not OK</mx:String>
                </mx:Array>
            </mx:dataProvider>
        </mx:ButtonBar>
        <mx:TextArea id="result" editable="false" height="100" width="100%"/>
        <mx:Button id="evaluate" label="evaluate result" click="printResult(event)"/>
    </mx:Panel>
</mx:Application>

The compiled version:
I want to get the first element of my "tmps" xml document. Casting the string to a XML document and work on it as a XMLList prevents me from getting the first element in the XMLList as long as the element doesn't contain a child! That simply must be a bug.

I admit it is not the largest bug in the world, but the consequence of a bug like this seems larger than I first thought.
As the xml and ui components both are a part of the platform, the solution seems to be an upgrade of the flashplayer as Adobe fixes the bug. Upgrading the flashplayer is something the enduser as to do.

As I am working on a internal flash/flex application that has to run in a closed environment, where ugrades of the flashplayer are something that is out of the hands of the enduser, an upgrade of the flashplayer may not be a trivial process.

A "watercooler talk" led to a interesting suggestion to how Adobe could structure the platform to lower the impact on the end user.
What if the xml api was some kind of versioned module that your flex application dependend on?
Then you (as a developer) just had to change your internal dependencies as bugfixes and new features was available.
Adobe could have something like a centralized repository existing of original (signed) modules.

The local machine running the flex application could have some local repository for downloaded dependencies. Each dependency could be resolved at runtime and downloaded as needed.
That would lower the time it takes for adobe to release a bugfix, as it doesn't involve a complete new flashplayer release and the issue where endusers doesn't have the privilege to upgrade a plugin is gone as well.

If the idea looks like the java/maven dependency architecture it's not a coincidence :-) Maybe flex /flash could learn from the java world in this case.