On Sun, Jul 26, 2009 at 20:59, Frederic Simon<[email protected]> wrote: > Maven is like democracy: It's not perfect, but that's the best we got! > Frankly, it's amazing how much frustration it generates. During the whole > discussion it's: > "How do I do XXX?": "I don't even know where to start, how to target my > problem?", > "It's possible but hidden in an obscure plugin", "You can, but it's against > the Maven way", "You can but you need to suffer first", ... > I think the feeling of being lost in front of Maven is the most annoying > feeling I had as a developer.
I've been using maven for at least *three years*, and this isn't the firs time I've thought of quitting it. (I'm just taking my second stab at working my way through the docs for Ant+Ivy.) We'll see what I find this time. It's a complicated story with many factors to consider. Tool integration is also an issue. m2eclipse is much like maven: it sucks and it's amazing. Maybe the eclipse Ivy plugin sucks less? Or more? Too often maven has the feel of a half-conceived design that got implemented too early, or it's just got so diffuse through it's plugin architecture that no one sees the "whole" well enough to address its contradictions. Most recent peeves: Version ranges don't work at all. I've only tried to use them *twice* in three years and both times I got myself into serious trouble. Most recently 0.9.9.200907201117 build of m2eclipse barfed on a dependency which used a version range to specify one of its dependencies. This pom had caused no trouble since release in November 2008, and now suddenly with the upgrade from 0.9.9.200907071528 it blows up on me. I recently added a few (non-snapshot) proxies to our central maven repository (nexus) since I needed them to build some JIRA plugins, and suddenly found my builds failing because maven was trying to use SNAPSHOT versions of among other things javadoc-plugin for all builds. This despite the fact that the super-pom included with mvn 2.2.0 specifies versions for at least some of the affected poms. I can only imagine that one of these repositories contains some botched releases of maven plugins which pretend to be official, but aren't and in fact depend on snapshot builds of other plugins. The "Maven Definitive Guide" explains that the submodule relationship need not be the inverse of the parent relationship. The one is for containment and build coordination, the other gives you a way to factor out common configuration. That made sense to me when I read it and I hadn't realized before that these two relations were in fact separable. The same, apparently, can be said of the people that wrote most of the maven plugins because, of course, it's utter crap. Site-deploy mangles inherited deployment management for sites by adding directory levels for parents, which only makes sense if you assume that parent and submodule relations are inverses of each other. It's the accumulation of little stuff like that which makes maven feel like a tool that works by accident, not by design, and that does not fill me -- as the one responsible for our builds -- with the warm fuzzies. > But, Maven already change the build game, we need more dedicated developers > to improve it. The fact that the current maven code base is *very* hard to get a handle on has hurt the project. I hear they're working to improve that for 3.0 and I do hope they succeed. As it stands though, the documentation is terrible and reading the source is little help to me because there's a lot of magical injection voodoo going on to transfer information from POM to various properties on various mojos and then it's not at all clear to me from reading the code *when stuff happens*. I flailed around for far too long trying to figure out how to make maven's webstart plugin build JNLPs. I spent time digging through the code, hoping to figure out why it wasn't doing what we needed and how I might fix that. I couldn't even convince myself from reading the code that I understood how the observed behavior came about, never mind finding a place where I might make alterations to change said behavior. Hopeless. I do hope they have some luck making the code more approachable. If the code isn't made more hackable, I'm afraid that this will kill maven in the long run. I'd like to contribute, but right now it's almost too much work just making the darn thing behave consistently. And yet, despite all this, I'm still using it? Am I daft? // Ben --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
