Hi,
I just thought I would write down the reasons for me putting that much effort in adding Maven support to Flex. I know that currently most people will be using Ant builds or FlashBuilder builds. Nevertheless I think Maven is essential. 1. For the last 4 years I have been working as a consultant for helping big companies transition from Ant to Maven. No new project being setup (at least none I have come across) is setup using Ant nowdays in the Enterprise sector. Not being able to build with Maven would be a showstopper for many customers. I know that currently I'm doing no flex at all, but I am hoping on a second renaissance of flex as we provide FlexJS for the masses. 2. In Ant you describe step by step how you want to do things. This results in a large chain of commands which greatly differs form project to project. I have to admit I have not come across two projects in the Flex ecosystem built with Ant, which handle the downloading of dependencies the same way. If I wanted to add the flex-tool-api.jar for example I had to reverse-engineer every projects build in order to find out where to put stuff (and I have to admit I'm not 100% sure if I did it right ... it just works now). This is one major disadvantage of Ant for me. If you enter a project you have to dig hard to understand each build. 3. Cause Ant is so flexible, you start doing messy things: When trying to create a Maven build for Falcon for example I noticed some classes have to be compiled in order to be run a few steps later in order to generate code that is then used in a second compile run which then compiles all. Mabe it's just my esthetic mindset that is sort of disgusted by stuff like that. In maven you would have split up the project into 2 separate modules ... the generator and the project and all would be clean. 4. Being able to do everything makes people start doing everything. If it's good or bad. Ant is a great tool in the hands of an experienced software engineer, but is a weapon of mass destruction in the hands of a sloppy one. Unfortunately the world is full of sloppy ones ;-) 5. In an Ant build you usually download resources from remote servers. Assuming the possibility for a server to be offline with 5% chance (not only the server inavalability is a threat but changes to the server or new versions can cause failures) ... if you have 10 different servers you rely on the chance of a successful build sinks to about 60%. Actually we can see one example nicely with our installer. Adobe changes something on their servers and BAM! our installer stops working and has to be adjusted. Enough about the problems I see with Ant let's come to why Maven is great ;-) 1. When creating Maven a lot of people with a lot of experience came together and sort of developed a recipe for building projects. They came up with a list of phases every project goes through (or can go through). In maven you select a "packaging" in your pom.xml for your project and this loads a sort of template that tells maven: when doing a "jar" build, in phase "compile" run the plugin goal "compile" of the "maven-compile-plugin" with the sources in "src/main/java" ... in phase test-compile, run "compile" of the "maven-compile-plugin" with the sources in "src/test/java". So you could build a jar with only 6 lines of pom.xml if you want to use the default, but you can add other plugins to your build, re-configure the default ones and adjust the build to your needs. The only thing you can't change are the phases the build runs through. Things you have to do in every project and over and over again are usually already part of Maven (dependency resolution for example) or are available in default plugins. If you need something that doesn't exist, simply write your own plugin and use that. 2. The inflexibility of the build itself forces the developers to build each build according to the maven rules. Even if this might sound as a bad thing, it's actually a good thing. As anyone can enter an existing problem and understand how things work, because they all follow the same rules. For me working on BlazeDS was easy for example, cause I could concentrate on getting the Testsuite running and could ignore having to learn how the build works. 3. Maven solves the problem of having to communicate with other servers by the concept of repositories with a fixed and standardized structure. There is one big central repository serving most of the artifacts you will need, so the chance of a successful build is far greater than by communicating with different servers of different projects. As companies would never rely with their life on the availability of one system that's not managed by themselves Maven allows running own Maven repositories which are usually configured to cache and act as a proxy to the other systems. In this setup the Maven build in the company asks the company repository for the artifact. If it's there, it sends this back immediately. If it's not available it looks in other repositories and gets it from there. From now on it servers the cached version without having to contact the other system about this. This way the company can be sure to have all the libraries it needs available and are even able to include this in their own backup strategy. 4. As Maven has a strict way of building, it is easy to build tools that understand the maven build. CI servers can extract information from the build perfectly, IDEs can provide a far greater level of assistance. 5. I haven't encountered a single project that wasn't buildable by Maven. Every time someone said: It's not possible, the problem was actually having a sloppy structure in the project, cleaning up and splitting up solved every problem. Ok enough of my love-letter to maven :-) Chris
