> > What you write below is why Maven is hard. Because it wraps up complex > patterns into small entities like commands and profiles, you aren’t always > able to tell what is going to happen until you try it. Whereas in Ant, > you can always read the script. But that’s not to say it is bad, it just > requires more learning. > > Another analogy is manufacturing companies that periodically change what > they produce by reconfiguring the assembly line. If they are baking > cookies for one retailer, they simply plug in different boxes for the > packaging part and different ingredients in the mixing part. Then they > cah bake for a different retailer by changing boxes and ingredients. > That’s Maven. The default behavior is designed to mix something, bake > something, cool it, and package it. But if you want to vary from that > formula, it takes experts to do it. > > Ant is baking at home. My mom has made dozen’s of batches of cookies of a > particular recipe, but when she passed the recipe on to me, I can make > changes to the process because the steps are smaller and easier to learn, > but in doing so I can also goof up and forget to cool it, or put the > frosting on before putting it in to bake. > > I had the same Ant vs. Maven mentality for a while before it clicked to me that the comparison is irrelevant. I have Maven setups that actually invoke Ant targets (Ant is available to Maven as a plugin)
The biggest advantage of Maven is its dependency management mechanism. For a Flex project that you, me or anyone in the world creates, we know that the minimum dependencies are the Flex SDK and Flash Player global. These dependencies can be managed in a global server that everyone can access. This means that there less (almost zero) configuration on the end users' side. If your individual project has additional dependencies, say on a Flex library project, yes you need to do more work. This does not mean that the defaults are bad. It is just that you are in a smaller group that needs more than just the defaults. You can always use an Ant plugin to build that swc, deploy it to a local repo, and the maven install task will resolve the dependencies while building the main app. In a team setting, you can have a team working on a shared Flex library project which gets released once every few months. There could be other teams that depend on this library, but are on different codebases themselves. In this scenario, the team building the shared library releases a .swc artifact with a unique id. Every team can then use that deployed .swc when building their own app. You can do the same in other ways, for ex. by requiring each team to download the source from a release branch of the shared library, build it every time or simply store it themselves. Again you have the problem of storing a binary file in source control which will lead to its own problems. Maven (more or less) elegantly solves this problem. Thanks, Om
