On 5/25/06, Chas Douglass <[EMAIL PROTECTED]> wrote:
After struggling for the first week with broken links and dead-ends on
the web pages, I subscribed to the users list and found out there is a "secret" book that documents much of Maven (ok, it's not really secret, but should I really have to subscribe to a mailing list to find out there is more documentation?).
+1, the book should be mentioned somewhere prominently on the maven website. So now I'm using a "stable" product (incorporating several unreleased
and poorly documented snapshots) and what happens? New releases of a number of modules come out and everything breaks! Have I specified a release where I shouldn't have? Have I NOT specified a release where I SHOULD have? Based on the limited traffic of the problem on the user's list, I can only conclude that most people that use Maven are building the plugins/modules and that very few people actually use it to build applications.
As others mentioned you can specify the exact versions of plugins to be used, and if you are using snapshots you can configure the pluginRepository where it's retrieved from to __never__ search for updates.
You have this wonderful archetype mechanism, why don't you use it to make a pom.xml that actually includes information for everything it does? This would be self-documenting to developers. Isn't the target audience developers?
http://maven.apache.org/ref/current/maven-model/maven.html I believe Maven is hiding the actual build structure, and that that is a
bad thing. I have used a number of open source projects where the configuration file is used to document the product! It is MUCH more enlightening to see a comment with a commented-out section than, well, nothing.
This is called "configuration by exception". Some developers actually enjoy sifting through hundreds of properties to tweak, others don't. It's a matter of preference really. I for one expect things to initially work out of the box, and after things get more complicated i'll start looking where and how to tweak, not the other way around. THE CENTRAL REPOSITORY PROBLEM
I think the second major design problem is the central repository. As evidenced by the hardware failure at codehaus.org, this is a single-point-of-failure that is simply unacceptable in real world build situations.
+1, many ppl got hosed during last week's outage of codehaus.
CONCLUSION: I think Maven is just "not ready for prime time". I really want to like it. I think there are some great ideas, and clearly some really smart people working on it.
-1. maven is ready, but it depends just how you define 'prime time'. You clearly have a very good understanding of how build tools should work in a project. I suggest you try to stick around a bit longer and learn how to bend maven2 to your advantage. HTH Jorg
