I agree on all points :) On Nov 14, 2014 11:50 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote:
> 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 > >
