Hello,
I would like to throw my 50cts in the discussion, drawn from my
experience teaching maven and consulting about software quality and
SDP in general, so-called "maven expert" - not that I claim the title
anyhow :-).
The first piece of information that is missing, IMHO, is a bird's eye
view of how maven is working, the underlying concepts and best
practices behind it, which is often summarized as "convention over
configuration". It is difficult, as a teacher, to make people grasp
the workflow of using maven: They usually stick to a procedural view
(eg. à la Ant/make/scripts) which is obviously the wrong way as maven
is not designed that way.
I very recently gave a four days course on maven to experienced
developers and PMs in a big company which develops a lot of
software. The overall tone was that of Patrick's post: 1) maven looks
great, but documentation, beyond "Hello world" and below plugin
development is poor/badly organized; 2) it is difficult to have common
tasks (eg. moving files around, knowing which dependencies are used
and can be excluded...) done quickly; 3) XML sucks.
Let's put 3) aside for now on.
When you explain the inner workings of maven: dependency management,
reactor, plugins, projects' structure, repositories (and those dreaded
snapshots), standard phases, the rest - profiles, filtering, testing -
sounds generally clearer:
- one can cleanup the mess in 1),
- it becomes obvious why 2) happens and you can start thinking the
maven way.
I did a small exercise. I asked the attendants to provide me with a
sample project they were currently working on and we worked together
on mavenize it. We started from a custom ant-based built project,
where the build.xml is generated to 3500 lines of ant from a project
dependency description (ie. dependencies) and which amounted to
300kLoc of java. We ended up with a plan for mavenization that
emphasized the strengths of maven: eeasy dependency management,
parameterized assemblies for various build targets, simple POMs with
small grained components breakdown... The net result was really
convinced (at least on a whiteboard) and helped the audience improve
their understanding of maven.
Based on this and other experiences, I could suggest the following
actions to help improve maven's documentation and so called 'user
experience'. Note that these proposals are partial and I also think
that improving UI of maven's sites would also help.
1. Keep a "getting started" or "maven for dummies" section prominent
on web site
2. Add in second position a "How it works" document, with highilights
of the implicit assumptions about Software Development Process
behind maven
3. Add in third position a "Transitionning from Ant/make/whatever"
document, with a concrete example of a project's transformation
4. Add a "Pros and Cons" section that would highlight what is easy
and what is hard in maven
To address point 3) above, I definitely think that providing some sort
of simple language beside XML to defines poms would be great: Although
XML is widely known, it is not widely loved and tends to create
cluttered POMs.
My 50 cts,
--
OQube < software engineering \ génie logiciel >
Arnaud Bailly, Dr.
\web> http://www.oqube.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
