Whenever I'm trying to sell maven to a manager/management-type group, I ALWAYS describe it as a codebase management tool, which is MUCH different. We all know that maven has little to do with managing deadlines, requirements, etc. In fact, it has very little to do with any other phase of SDLC (or whatever flavor you prefer) than implementation, testing, and deployment (not a *real* phase, AFAIK). Also, maven seems to fit best in helping that one unsung developer who inevitably becomes the build nazi for the group, running around pounding on people who break the build. Managers often don't seem to recognize it, but one person often spends most of his/her time doing this - unless he has introduced maven into the process. I call this role codebase management (unsure if that's a real thing out there...not claiming I coined it), and the term seems to get the point across. Seems like many people have a hard time "getting" maven because they've never considered the codebase manager a real role...it's like:
Step 1: Write Code Step 2: ... Step 3: It runs If only code would self-organize, self-configure and self-deploy (oh, and self-document, self-meter, self-...). If we want to sell maven as the Way of the Future(tm), then we need to make sure the criticality of actively managing your codebase is well understood first. Just my 2-cents. -john On Sat, 2004-07-17 at 21:15, Brett Porter wrote: > Hi Jason, > > Thanks! I certainly can't take all the credit - a lot of folk have been > hammering away and cleaning up the plugins , especially those that took on all > the releases in the last few weeks when I didn't have the time. > > Reading the posts on slashdot was a helpful reminder: we should take care in > describing Maven so it is not perceived as a project management tool in terms of > Microsoft Project, but as a Project Software Management Tool. Its not about the > build, but it is about the code. > > I'm pretty happy with the result: all the behaviour is now well-defined, even if > it is not optimal. That's a stable base for users to stick with and upgrade > their plugins for as long as Maven 1.0 lives, which is great. My only > disappointment is that I didn't get the time to fix the documentation like I > would have liked to. I think there are some fundamental issues that need to be > sorted out, and I'd much prefer to be maintaining living documentation on > something like Confluence, while leaving the release specific stuff to what is > kept in CVS and published. > > Cheers, > Brett > > Quoting Jason van Zyl <[EMAIL PROTECTED]>: > > > Howdy, > > > > The guy only talked to me yesterday but it went up quickly and showed up > > on slashdot which I didn't expect: > > > > http://www.internetnews.com/dev-news/article.php/3381841 > > > > The one thing I've ask to have correct and which I specifically > > mentioned is that the release would not have happened without the work > > of Brett. I'm listed as the release manager which is not the case for > > 1.0 at all. Brett has done the last few releases and 1.0 has seen the > > light of day soley because of him. > > > > -- > > jvz. > > > > Jason van Zyl > > [EMAIL PROTECTED] > > http://maven.apache.org > > > > happiness is like a butterfly: the more you chase it, the more it will > > elude you, but if you turn your attention to other things, it will come > > and sit softly on your shoulder ... > > > > -- Thoreau > > > > > > --------------------------------------------------------------------- > > 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] -- John Casey [EMAIL PROTECTED] CommonJava Open Components Project http://www.commonjava.org --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
