If XML is the problem for Maven, why is it not for Ant. Can anyone claim that a makefile's syntax is any easier to understand? In addition, make isn't procedural or sequential and that didn't, back in the day, generate loads of comments.
It's not that you really were arguing the "pro" side of those arguments, But IMO the arguments about how 1) XML is a pain and 2) Maven is not procedural are not truly problems but for some reason they bother people in the context of whatever is really bothering people. (I don't claim to know what that is but it seems to exist.) -- Lee On 9/27/07, Insitu <[EMAIL PROTECTED]> wrote: > > 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] > > -- -- Lee Meador Sent from gmail. My real email address is lee AT leemeador.com
