I had a relatively short run-in with Maven about 4 years ago and it left me thanking my lucky stars I wasn't the one maintaining our builds. I ran back to Ant for my own projects as fast as I could. Why does a build system itself need to be smart? If I want dynamic behavior out of a build system, I can extend it in specific ways to accommodate my needs. Why should your every single interaction with it be viewed through its, rather than your, world view? I've set up lots of projects by hand, mostly with Ant, and the number of instances, where I needed dynamic behavior is miniscule. Yes, I occasionally copy and paste Ant code from an older project into a brand new one. So what? I like the fact that I can come back to an old project with a dependency to an outdated library and recompile it and not have to worry about anything breaking because Ant decided I should compile against a newer version of that library under my nose. At least out of my build system, I want predictable behavior as much as possible. Maybe I didn't give Maven enough time or thought, but what I really don't get is why those who feel like they need this dynamic stuff in a build engine don't look to Ant extensions that can do the same thing, only in a more localized fashion.
Alexey ________________________________ From: B Smith-Mannschott <[email protected]> To: [email protected] Sent: Monday, July 27, 2009 9:45:49 AM Subject: [The Java Posse] Re: "Maven Without Pain" was painful just to listen to 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 -~----------~----~----~----~------~----~------~--~---
