I think this answer is one of the common problems with Maven. I don't mean to pound on Emmanuel, who's doing a great job, but just point out a very common problem in many open source projects.
The fact that a feature is available in a snapshot version or in the trunk doesn't help the user that much. Unless the feature is actually released, it doesn't do much good. My experience with Maven (and particularly the plugins) is, that errors are often fixed quite fast after they are reported. But from then, it can be quite a long time (often months), until the fix is actually released. In that period, everybody affected by the bug has to use snapshot versions, or build the plugin themselves. Snapshot versions are not great if you are trying to run a stable build environment, and building everything yourself from the trunk, means living on the bleeding eddge, with lots of snapshot dependencies. I think a good solution to the problem would be more frequent milestone builds (both core and plugins), and a publicly available road map, giving people a good indication of when they can expect to see what released. Best regards Simon Kepp Nielsen, Configurations Manager PFA Pension, Teknisk Arkitektur Mobile: +45 30 52 77 07 E-mail: [EMAIL PROTECTED] PFA Pension Sundkrogsgade 4 DK-2100 Copenhagen OE Disclaimer This message is for the designated recipient only and may contain confidential or privileged information. If you have received the message in error, please notify the sender by replying the e-mail and delete the message without copying or disclosing. -----Oprindelig meddelelse----- Fra: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sendt: 30. august 2006 11:43 Til: Maven Users List Emne: Re: [POLL] Why switch to Maven? Jan Vissers a écrit : >>> 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? It's implemented in snapshot version of javadocs/jxr plugins Emmanuel > >> 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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
