A View From Above comments

"The Things That Are Wrong With Maven" by Bruno Borges

Tue, 28 Oct 2008 03:24:59 -0400

Too much yelling... Do you really know how to use Maven? Seriously, usually people complain about something like this just because they don't know how to customize or are too lazy to read the docs/sources. I work in a project with thousands of build.xml and I hate it. I wish they've used Maven... :/

"The Things That Are Wrong With Maven" by Bruce Snyder

Tue, 28 Oct 2008 02:02:00 -0400

Ted, I switch back and forth between m2eclipse and the command line all the time and I don't have any issues.

"The Things That Are Wrong With Maven" by Ted

Mon, 27 Oct 2008 18:27:09 -0400

@Bruce, maven eclipse plugin is awful. If I do "mvn clean install" from command-line, then the maven eclipse plugin would cry saying that some of the class files on eclipse are not there (not being built, whatever)

"The Things That Are Wrong With Maven" by Psynix

Mon, 27 Oct 2008 16:47:38 -0400

I'd recommend the open-source Quokka ( http://quokka.ws/ ) which addresses many of issues you've raised.

"The Things That Are Wrong With Maven" by Bruce Snyder

Mon, 27 Oct 2008 15:51:09 -0400

I have used Maven for many years since the beginning of the project and although it has some inconveniences, most of the complaints offered here are common among folks who want to completely customize Maven which works against the whole idea of a Maven project.

Maven has many great features and benefits, but the biggest advantage is the ability to move from one project to another without having to take the time to dig through each project's build to understand it before even getting started coding on the project. With Maven and it's project style, I can move amongst many, many projects without stopping to dig into the build. If you want to customize the project structure or adapt it to a legacy project that doesn't follow any conventions, then yes, it's gonna be painful.

Verbosity - If you're not happy writing XML, then use some intermediary technology such as Groovy that will spit out the XML for you.

Working With Legacy Code - This is most commonly a result of many, many, many projects all crammed into one source directory and using the package path as the separator. This is difficult no matter what build tool you're using. I've worked through these style of projects either by using small hunks of Ant scripts or by creating different assemblies for subsets of a huge project (this breaks it up into smaller modules).

Transitive Dependencies - I've never had much issue with this feature, in fact, I like it a whole lot better than trying to manage dependencies all by hand and checking them into SCM. Regarding the POM errors, the blame for crappy POMs lies squarely at the feet of the projects who own those POMs, not Maven.

Flexibility and Plugins - I've found that there are more than enough plugins available to handle the situations I've encountered. And if I can't find a plugin, I do use some sort of scripting and I don't find it to be a big deal.

Unit Testing - The right plugins and tools can make this task much easier to handle, but I've not found an easier way to work with unit testing yet.

Build Output - Agreed - I'd like to see this be configurable.

Repositories - All I can say is that you need to start using Nexus (http://nexus.sonatype.org/). It will alleviate all of these issues and it beats the hell out of all the other repository managers.

File Structure - This can be customized either using the properties that are available, using the includes/excludes capability or using the assembly plugin. Yes, this is kind of a pain to set up, but when the build structure is non-conventional to begin with, there is no easy solution.

One last suggestion I'll make is for the use of Maven with Eclipse via the Maven2Eclipse plugin (http://www.eclipse.org/m2e/). This plugin dramatically simplifies the use of Maven for Eclipse developers. Anyone using IDEA already has pretty good support and I'm told that Netbeans has good support for Maven as well. I've found that simplifying the use of Maven from within the IDE smoothes the road quite a lot for developers.

"The Things That Are Wrong With Maven" by Ivan

Mon, 27 Oct 2008 11:15:55 -0400

Both Spring and Guice are good at adapting to your style of development. This is my main complaint against Maven. It forces a style on you that may or may not work with your IDE/methodology etc. Ant is an incredibly flexible and useful technology for builds. My typical build file is about 20 lines max and reuses macros I've created across multiple projects. All directories/parameters are completely configurable as well. Maven is nothing like that. I like the concept of formalizing a project, but I think the implementation is unsatisfying at best. dependency management is a nice thing though, and I'll probably investigate Ivy going forward.

"The Things That Are Wrong With Maven" by ben

Mon, 27 Oct 2008 10:51:12 -0400

Maven is all that is evil with java developers. Like spring. Guice is the cure for springs evil. But there is no similar alternative for maven unfortunately. Perhaps java developers forget that if they move from java into another tool (properties, xml etc) they lose all the benefits of java's tooling... which always ends up in pain. It's like eclipse + osgi = unstable piece of crap.

"The Things That Are Wrong With Maven" by Ignacio Coloma

Mon, 27 Oct 2008 10:06:47 -0400

Somebody that can compare Buildr with Gradle? I'm giving some time to the latest, and am quite satisfied with the results so far. For the record, there have been implementations of a less verbose XML file format for maven, and it was pulled back because of "backwards compatibility". To me, that's a symptom of a project that will not evolve past this current state of dissatisfaction.

"The Things That Are Wrong With Maven" by Adrian Tarau

Mon, 27 Oct 2008 10:00:26 -0400

First of all Maven is far from perfect. It has bugs and the documentation is not as good as it should be. But still I find posts like this one misleading. 1. Verbosity Do I need to say anything here? Nothing is wrong with XML...at least not for this taks. It is debatable when too much is too much, but definitely is not too much for a build tool. 2. Working With Legacy Code You can build your project with Maven in parallel with what you have and when you determine it is complete you can make the switch. 3. Transitive Dependencies You can control those dependencies, there is nothing scary about this one.There is a big difference in controlling all dependencies versions and only what's critical for you : application libraries, critical building phases. I don't think it will hurt you if the generated Maven website could be affected by "minor slip-up". 4. Flexibility and Plugins Flexibility means you are flexible to extend the current building process not that it will provide everything for every project. 5. Unit Testing I hope you're using a Continuous Integration Tool, if not I would recommend Hudson or TeamCity(free for 20 build configurations). Who said you have to analyze 10Mbyte of log files to find which test failed? Use a tool for that... 6 Build Output Just hoping you're not running with -X switch :) 7 Repositories Is it too much to have a file system and an Apache HTTPD daemon somewhere? Nobody said to manage your repository with an application, but if you want a better view of your repository your can try http://nexus.sonatype.org/ 8.File structure The current file structure is a recommendation(one that makes sense), you can changed it with 3-4 lines in your POM file. I could go on all day… As I already said Maven is not perfect but still ... Instead of writing blogs like this one, go on JIRA(it is open 24/7) and make suggestions, provide patches or even write better plugins. PS. I'm not a Maven developer, just a simple user.

"The Things That Are Wrong With Maven" by anonymous

Mon, 27 Oct 2008 09:28:46 -0400

I'm using maven for about 2 years. NEVER GOT A SERIOUS PROBLEM. I've 3 projects builded on: - 1 windows XP - 3 windows vista - 2 gentoo linux - 1 suse linux - 1 macosx I'm using all the standard plugins (assembly, archetype, war, etc) plus some fancy plugins, like hibernate3 (in order to build the mapping documentation). I'm also using pom composition and inheritance (DRY, don't repeat yourself). I've also embedded maven to build some parts of another application from java. I've also written plugins on my own (to replace an unsupported plugin) but it was a task of an hour! :-) The *REAL* problem of maven is the DOCUMENTATION and the maven API is still for java2, no java5 features :(