Chas,
For what its worth, a couple of months ago I posted similar sentiments,
and so I second your thoughts here. I didn't really go through a list of
the issues I faced -- I focussed primarily on the documentation. The
Megere documentation is a significant improvement, though I also
recognize the curiousity of it seemingly existing separate from the
project documentation.
I am using Maven 2 successfully, with maven-proxy in place, and it works
fairly well, but I do dread issues that come up in our work that require
variations to pom.xml configuration, as there's never any telling how
long it will take to resolve an issue.
I appreciate you being brave enough to post your thoughts. I welcome
them, and share your sentiments. But I've kind of backed off on any real
discussion of this, as I realize that not everyone grasps or agrees with
the irony of the requirement to dig into source code to merely use an
OSS library. Once you cross that threshold and get involved directly
with source code, it turns a major advantage of OSS (time/licensing
cost) into merely a shell-game, where the development cost is shifted
from coding and having complete architectural control to reading someone
else's code and having no architectural control. I just think its a
pity, because Maven is obviously the product of a lot of hard work, and
such work shouldn't be marginalized. Without going into a diatribe here,
it seems that everyone would tend to agree with the notion of
"interface-based programming", the general tenant being that integration
points in applications be defined via well-defined, clean interfaces.
However, it seems that this principle is completely ignored from a
customer/product standpoint -- the "interface" in this relationship is
the clear definition of the use of the product, so leaving this
interface unattended to basically obfuscates great functionality behind
a convoluted interface.
Its perfectly fine if others see it differently -- I'd guess most
probably do. Its just as I reflect on the curve incurred to convert to
maven, it was more steep and unexpected than originally thought, not
because of complexity, but more because of the hunt for answers, and
subsequent trial and error And additionally, I'm getting similar
feedback from others I know who are attempting to use Maven.
But again, the Megere book, though I haven't been able to read it all
yet, it looks to be a really good resource.
Brad
Chas Douglass wrote:
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.
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.
THE DESIGN PROBLEMS
But my real beef comes to design decisions that I think needs some
serious consideration.
MAVEN HIDES TOO MUCH.
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.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
