>>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".
I would like this approach very much, but... have you tried to publish javadocs/jxr/surefire/pmd... etc for a multimodule project in an aggregated fashion? > 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]
