On Wed, August 30, 2006 7:37 am, Jan Vissers wrote: > I'm reading a lot of "we need about x weeks to convert to maven", "the > learning curve is steep", "it is messy but it works", "if it cannot be > done we can use ant"... > > More and more I'm getting the feeling that ANT still isn't such a bad > idea for building software. You can do a lot of the convention over > configuration stuff for your own projects with ant and things like > macrodef, subant and antlib. For dependency management we're currently > using Ivy - which is pretty descent. What's more the reporting just > works, even aggregated > (pmd,jdepend,junit,checkstyle,cobertura,javadoc,changelog,javacnss). > > Can somebody tell me what the main reason would be for changing from ANT > to Maven? > I'm starting to get serious doubts.
I recently got involved in a project whose build system uses ant + ivy, and to sum it up: what an inefficient mess. Within themselves, ant and ivy are worthy tools, that perform their tasks well. The real problem is that once developers get hold of them, things quickly go pear shaped. The key biggest problem with the ant + ivy combo is the fact that developing the build system is a secondary concern, the primary concern being developing the software itself. This causes numerous problems, including: - ant scripts are often half finished. In this project, nobody bothered to take advantage of incremental builds. Any attempt to build, will build clean - a huge time waster. - ant scripts are almost always riddled with hard coded paths, and developer specific customisations. In this project, that means that every developer has to set up their development environment the same way as the other developers, which may seem perfectly acceptable to some, until you realise that developers don't just work on one project. This makes it difficult / impossible to introduce continuous integration techniques, despite this particular project desperately needing it. - ant scripts are often riddled with relative paths to other projects, where it is assumed a sister project is checked out. Again, this prevents continuous integration from being possible. - ivy dependencies are often set up by developers who fiddle until they work. In this project, the eclipse jars were removed from their plugins, had their version numbers removed, and dumped into one big ivy dependency called "eclipse". There is no way of knowing what jar offers what functionality, because the jars are called sac.jar, core.jar, etc. Upgrading the jars (to take advantage of a bugfix, for example) in this project is very impractical. To sum up the above: Giving developers the power to "do what they want", simply means that developers are given the power to do something badly, or not at all. Build systems are always secondary to the primary code, and do not receive proper attention from developers, and this wastes copious amounts of time, and therefore money. Maven's key strength is to say "don't worry about trying to build a jar / war / ear / sync with eclipse / autorun tests / publish javadocs / etc / etc, because I already know how to do that, you go and do what you do best, work on the primary code". Regards, Graham -- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
