I've been struggling hard with Maven this week, and its really be bringing me down. I love the theory of Maven, but the execution is so awful I'm very close to eating crow and switching back to a Ant build, maybe using Ivy.
One of the things that concerns me with Maven is that for a tool whose goal is to be a "project comprehension tool" (giving quick access to Java source, Javadoc and other reports) it's almost impossible to find the source or get any insight into how Maven is built. Yet so much about Maven is impossible to find, with broken links, missing and out of date documentation, and other hazards running rampant.
I've been hunting around for 30+ minutes, trying to find the source to MavenCli. It's in the maven-core library. Good luck finding a link to that off the Maven web site. Through arcane means and Google searches I eventually stumbled across http://maven.apache.org/ref/ but 2.0.7 is not present there. So they rolled out a release without external documentation? I guess that's OK when you need a magical incantation to even find the documentation.
Well, I'm getting closer to my answers, but I'm probably still shiv'ed because Maven developer guidelines mandate zero documentation in the source. Or anywhere else. In fact, I believe the maven-fuckyou-plugin exists to strip documentation out of your source and seems to be enabled by default in all the Maven modules.
Well, eventually I answered my own question: -Dmaven.repo.local=directory allows me to control where the local repository exists. This is for my Bamboo server that needs to build multiple branches that share the same version numbers, so I don't want them to use the same repository.
Anyway, that's what it should be (from the tiny fraction of the code that's visible). But it blows up real good, apparently unwilling to download files into this repository, and spewing errors that make it appear as if artifacts were not present in the remote repository.
So, when Maven is useful it is very useful, but when it gets in your way, it totally blocks you.
23 comments:
Hi Howard,
I'm glad to see you blogging again.
Maven is good, helps a lot, but sometimes it is a pain.
I've had similar experiences, only I was truly blocked and end up sticking with Ant. I'll especially never use Maven after hearing about the no-comment policy.
I use rake for all my java builds now. It is useful for many sorts of build related tasks and easy to extend.
What I love about Maven is dependency management, including the transitive dependencies and all the related scopes.
I also like the (theoretically) integrated documentation. I like the APT format for getting docs written without getting hung up on formatting & etc.
I like building at the project or at the module level.
However, in practice, Maven is painful.
I often have to use a mix of technologies: some Ant stuff for more procedural operations, Ruby and/or Rake for other stuff.
Perhaps we'll scrap using Maven itself and just use Ant w/ the Maven Ant Tasks.
I used to want to use Maven because of its ability to handle deployment of documentation and artifacts. What I've seen recently is that the scpexe wagon is so slow its unusable. I've been changing my builds so that deployment is based on file: operations on the build server, which doubles as the host for the documentation and the remote Maven repository.
I feel your pain Howard. Its true that if you use Maven as the guide says everything will work "fine", but the moment you want to do something "fancy" it gets in the way most of the times =(
I'm still looking for an option that allows to switch a source file with the same name from a different source dir, I had to do the build with Ant and let Maven handle only dependencies.
I use Maven 2 at work and I don't like it. It is very fragile (it took us 3 days to build a release because of continuously breaking plugins.. the projects used quite a lot).
Personally I find Maven very vague.
And you are forced to jump through the hoops Maven provided, and as long as your project is standard, everything is ok.. but as soon as you want something special, you are in a world of pain.
Give me ANT any day. For my project http://prometheus.codehaus.org I use Gant (Groovy ANT). The power of ANT combined with the power of a full blown programming language.
Hi, Howard.
I feel your pain. Maven2 is good in theory (except phases), but it has very bad implementation with number of cryptic errors.
So, for my current project I've decided to use Buildr tool. It gets some ideas from Maven, but implemented on Ruby.
Check this out http://buildr.rubyforge.org/
How to change the local repository is documented at maven.apache.org/settings.html.
Furthermore, mvn --help clearly shows that different settings.xml files can be selected with the -s option.
As for source code browsing, take a look at http://maven.apache.org/guides/development/guide-building-m2.html for links to the subversion repository.
Maven has a high learning curve, but after 2 or 3 months struggling through, I saw the light. Now, I wouldn't do a project without it.
Actually, I think Maven has a learning stair, not a learning curve. In most projects, you get to a certain point and it opens up, but in Maven you struggle past one set of challenges, hit a little smooth sailing, then hit a new set.
On the off chance you haven't see it, Nabble is a good resource for finding answers to problems.
Bill ... I find that appalling! How does it matter how T5 is built, what counts is the end result, and that could be accomplished using Ant, Maven, Make, or a well trained troupe of monkeys. You don't need to use Maven to use Tapestry in your build process; there are traditional downloads as well.
I have been reading these comments and the same thing keeps coming to my mind. Convention over configuration. How many of all of your "special cases" are really special cases? Perhaps you are making the process too hard. Also, like any took, this one takes a little bit of time to learn how to use, and what it can do, and what it can not do. You weren't able to make Ant do everything you wanted it to do at first either.
Give Maven the time and focus that it needs and you will find yourself more productive than ever. Don't give it the time, and you can just keep complaining, and end up maintaining build files and dependencies for the rest of your careers.
Mike,
You're right. I'm being far too impatient. Let me use Maven for another full two years and then maybe it will be crystal clear.
My comments are from the point of view of someone who has already gone through the learning curve, has done some complex and elegant things with Maven, has created plugins and complex aggregated builds, and still has constant frustration with Maven and its related tools.
Early on with Maven I used to say to myself "I guess this is what noob Tapestry developers feel like", but I really don't think I've every subjected anyone to something as appalling as Maven.
Hi Howard,
I agree that documentation can be difficult to find and there is definitely a learning curve. Eric Redmond's book isn't mentioned on the Maven External resources site, and may be helpful. http://www.sonatype.com/book/
You can set your local repository in your settings.xml file in the conf directory as well as specifying it on the command line.
HTH,
Jim
I agree wholeheartedly with Howard about Maven. I too was really excited to learn Maven after reading its mission statement but then was cursing out loud when I saw the POS Frankenstein they created.
It's still the best system around right now (IMO) for what it does... and now that I've used it for over two years I'm pretty much melded into its craziness, but still I recognize what an abomination it is.
Someday we will laugh at how bad it is and all the pain we went through but that day is far away.
In my 10 years of software development, I've not come across a more sure fire productivity killer than Maven.
Ant works, and works fine. It's far easier to overcome Ant's shortcomings faster than you can over come Maven's.
My T5 adoption argument, really, is a politically-based requirement, not technical. I'll delete the post.
I had been using Ant for some time, and one of the things that had long frustrated me was my inability to create easily reusable build processes. I lacked a good way to define dependencies and relationships between sub-projects.
My current project needed really needed the reusable build processes that Maven provided but I had issues: nearly no one on the team was that familiar with Maven, the IDE integration (at the time) was dodgy as were the docs. The biggest strike against it was that we were unable to import all the necessary plugin's into our customer site in a reasonable way. It would have been nice if there had been an alternate distribution that contained more of the plugins rather than requiring you to pull virtually all from the internet.
Ant 1.6 + the Maven plugin (with a bit of tweaking), and a few custom ant tasks allowed us to get most of the same benefits of Maven, without all of the headaches. Our reusable build processes are built using Ant and utilize several Maven conventions.
It has worked fairly well, and has given us an easy migration path to Maven2 in the future if we decide to go that route.
But please, for the love of God, let's not change to yet-another-trying-to-be-
better-than-Ant build system. Even with all of it's faults, Maven is still far superior to Ant when it comes to maintaining builds; the pom won't keep growing indefinitely with yet another custom target and upgrading versions of dependent libraries is not the same hassle every time. Maven's a little daunting when you start with a new project until you've nailed down the versions of all of your dependencies, and especially if you are trying to do this custom thing with alpha-level plugins, *but* at least you can improve those plugins without having to re-write the core or having to manually try and install new versions.
Since you're already looking at Ivy, you may have run across this Ivy-biased post.
http://xhab.blogspot.com/2006/09/antivy-vs-maven-my-biased-opinion.html
Ant+Ivy definitely seems more 'knowable' and flexible. Someone mentioned reusable build stuff... In the impenetrable Ant docs, check out the subant task documentation for a beautiful nugget of information on reuse.
We too moved away from Maven and found that Ivy fits the dependency management bill. I like Ant over Maven for a similar reason I prefer Ant to Make: greater control. I also find that Maven violates the solid principle of "do one thing well" (in fact, it appears to violate that principle twice).
Post a Comment