On 2006-05-25 12:23:02 -0400, Chas Douglass <[EMAIL PROTECTED]> said:
I really liked the idea of Maven2 when I heard about it, and when a
fellow developer used it successfully to build a small library for me,
I thought it was time to jump in.
Three weeks later I have managed to accomplish very little on my
project, and I've converted four simple Ant build files into 7 Maven
pom.xml's that, by and large, don't work.
THE IMPLEMENTATION PROBLEMS
To advertise Maven 2 as "stable" is, I believe, a disservice to
developers. In my experience with it, "early beta" would be a kind
description.
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?).
Of course, the secret book also documents features that aren't released
yet (wagon is what bit me). Perhaps that's why it's secret.
Yeah, that PDF book "Better Builds with Maven" is a must. The
maven.org website does have information, a fair amount actually, but
seems so disorganized.
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.
It would be neat if you could execute some maven command and it would
"freeze" the plugins that you are using to the current versions when
you run the command. So in other words, it would modify a pom to
specify versions for plugins. Another idea would be for each maven
release to specify the plugin versions used that are involved in the
build lifecycle. (and that version must be fixed, not a range and not
a snapshot).
THE DESIGN PROBLEMS
But my real beef comes to design decisions that I think needs some
serious consideration.
MAVEN HIDES TOO MUCH.
Respectfully... I disagree with you Chas. I like that Maven hides
stuff. It hides stuff that is boilerplate and is the same.... or at
least *should* be the same across projects if you want a consistent
build environment -- which I appreciate. It's annoying to go to an ant
based project and then have to read the build script to know how it is
built. With maven, it's uniform. If you want an ant based build to do
something you didn't write in the build.xml... you have to write it.
With maven, you get it for free (assuming defaults and an existing
plugin that does what you want -- likely).
Of course... I think that if a system like maven is going to hide
boilerplate stuff from us developers and operate on defaults, then, it
is very important that there is clear documentation on what is hidden.
The documentation for maven isn't so hot, unfortunately. It would also
be useful if the output of maven (perhaps with a command line flag)
could more clearly indicate what it is doing and why.
It really is nice advertising to say "Look! This 12 line pom.xml
builds this huge project". But that's only if you happen to want to do
EXACTLY that ONE thing (which seems to be: build a Maven plugin). The
real world is more complicated. And as soon as I want to get more
complicated, Maven obliges me by getting WAY more complicated. Most of
this complication is due to, I believe, hiding too much from me.
Why is it that I'm expected, as a developer, to be able to download and
compile snapshots of plugins that aren't released yet (the jnlp
plugin), but I'm not expected to understand a FULL LIFE CYCLE build
file?
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?
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.
An example: I use Java 1.5. The Maven default is 1.4. Can I simply
search for "1.4" in the pom.xml and change it to "1.5". Nooooo. I
have to research which plugin actually sets this value, how it sets
this value, and add 9 lines to my pom.xml (assuming I did not yet have
any plugins configuration).
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.
If maven came with specified versions (not ranges or snapshots) of
build lifecycle oriented plugins, I don't think the central repository
issue would be the problem that it is now.
Not only does it represent a single-point-of-failure, it's not frozen.
I could never see my company using Maven unless we set up our own
version of the repository, and probably only if we used it exclusively,
since we require complete build reproducibility. Relying on an
external organization to not make "secret" updates (as has been
recently discussed) is simply unacceptable. I haven't tried to set up
a "central" repository, but from scanning messages on the user's list,
it sounds somewhat less than well defined.
Personally (for open-source projects), I can probably use it, but there
is going to be a nagging suspicion when something breaks.
So, for small users it represents a roadblock when the repository is
unavailable, and for large users it represents a reproducibility
problem.
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.
I hope this rant can be taken constructively. I want projects like
this to succeed, I really do.
And, please, I understand I'm one person. This is MY view of
attempting to use Maven to build MY projects. Perhaps I'm just not the
target audience. Perhaps I'm just out in left field. Perhaps I've
just missed the point completely.
Chas Douglass
~ David Smiley
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
