I agree with your comments about the documentation.

It needs some outside review to get the organization more oriented to the new person.

The definitive guide is missing some of the things that you need to actually build something functional.

I suggested some rewording and table changes and provided an example to the web page on transitive dependencies (http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies) to make it more readable by someone who does not know how it works but they were never incorporated.

The proliferation of plug-ins is also confusing. If you have a million supported conventions does that really help?

There probably should be a "Best Practices" document that describes the most productive ways to use Maven to do software development. It would likely be highly contentious for those who have developed some odd ways to do things. For most of us, we would just adapt if the "Best Practices" promised that Maven would be our faithful servant if we followed them. It would tell you how to structure your IDE project, how to manage your own libraries, how to deal with dependencies, etc. for different "normal" applications. It would give you examples of great parent poms, poms to build libraries and poms to build and deploy different types of applications (web, portal, web services, standalone applications) using your libraries and 3rd party libraries. There are probably 10-15 "Best Practices" that would satisfy 98% of software developers. The other 2% could read the Maven docs and explore the plug-ins.

Ron
Mark H. Wood wrote:
As good and as pervasive as Maven is, if you review build tools then you
may want to take a look at Ivy too.  I plan to.

Yes, Maven is hard to learn.  The web site doesn't quite seem to be
organized either for learning *or* for reference.  The only book I
could find when I went looking for one, _Maven:  the Definitive
Guide_, would have to be three times as thick if it were really
definitive.  Everything the new user reads praises "convention over
configuration" and then doesn't tell you the conventions.

Maven embodies some very definite ideas about how software should be
built.  If you try going some other way, Maven will smack your hand
over and over until you winkle out what it wants you to do.

Maven wants to be in control of things.  It downloads what it wants,
when it wants to, without asking.  It puts things where it wants to,
without telling you where they went.  You must accept this.  It is a
thing that goes down hard for many developers.

Maven is not readily discoverable.  The way to get basic help from it
is a complex formula that stretches all the way across the screen.
The usual ways of asking a tool how it works will yield either
reminders of things the newbie wasn't ready to learn, or a screenful
of seeming gibberish.

All that said, once you have scaled the learning wall (I'm maybe 40%
up) Maven will do a good job for you so long as you use it the way it
expects to be used.  I haven't given up on it.  (Oh, no!  I've
suffered enough that I won't rest until Maven cringes before my stern
gaze, whimpering, "what is thy will, O my master?" as a good tool
should.)



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to