Hi Wayne --
oh I don't think you guys need to get the list from everyone ... it is very
well impossible and trying to be "complete" is like trying to be "perfect".
It is usually not obtainable. The list I threw out was an example of things
that are simple without maven that seem to be close to impossible with
maven. This puts anyone trying to convince an organization to use maven in
a bad position. If you bring maven into an existing environment, maven
*must* be able to play well with others and non-"standard maven" directory
structures. But most importantly it must be able to do the simple things
that other tools (like ant, make, and shell scripts) can do.
The fact that it doesn't is the reason I have never tried to use maven
previous companies.
==============
Specific suggestions
==============
1. If maven has no pom in current directory. mvn should display help
similar to this from perforce:
Perforce -- the Fast Software Configuration Management System.
p4 is Perforce's client tool for the command line. Try:
p4 help simple list most common commands
p4 help commands list all commands
p4 help command help on a specific command
p4 help charset help on character set translation
p4 help environment list environment and registry variables
p4 help filetypes list supported file types
p4 help jobview help on jobview syntax
p4 help revisions help on specifying file revisions
p4 help usage generic command line arguments
p4 help views help on view syntax
The full user manual is available at
http://www.perforce.com/manual.
Server 2005.1/86945.
2. have "mvn help" be able to run out of the box with *no downloads*
being required.
3. have the concept of a reverse archetype -- mvn runs and figures out
what the pom.xml should look like based on the current directory
structure. Currently the archetype concept says "*if* you make your
directory structure look like this mvn can run". Most projects do not have
this luxury.
4. if a pom is "broken" mvn should offer a suggestion about how to fix
it.
Hope this helps... You guys have a good idea and I am looking forward to the
improvements.
-Pat
On 9/26/07, Wayne Fay <[EMAIL PROTECTED]> wrote:
>
> Your personal list of "stuff I don't know how to do, but should
> probably know" is specific to your experiences and expectations.
>
> My list is different. Everyone who reads this email probably has a
> different list in their head.
>
> How can we reasonably:
> 1) Get that list from everyone
> 2) Answer all their questions
> 3) Distribute this to everyone
> 4) Keep it updated
>
> This sounds like a FAQ or Cookbook. Well, we have a FAQ (and a
> Cookbook) on the Maven site, it just doesn't happen to contain your
> specific questions (yet). How do you propose we do a better job with
> #1 above? Then we can worry about 2, 3, and 4.
>
> I think this is as good an approach to fixing things as anything else.
>
> Wayne
>
> On 9/26/07, Patrick Moore <[EMAIL PROTECTED]> wrote:
> > Hi Brian --
> >
> > I certainly do agree with you that the maven website / documentation
> > definitely needs the improvements you outlined. However, if you are
> relying
> > on documentation to cover up for maven's deficiencies that is a waste of
> > time. Good documentation supports a good product but it can't be
> expected to
> > act as a band-aid for maven's usability issues.
> >
> > Now I use maven every day. So I am not throwing rocks from the sidelines
> at
> > all. I have used maven for a year. I am using it to build my company's
> > product. But I have neither the time, nor desire to be a maven expert.
> >
> > And that is the fundamental problem,:
> >
> > Software developers assume that the user is a novice who wants to become
> an
> > expert, or an expert.
> >
> >
> > There is no allowance for the reality that the vast majority of users
> are
> > **comfortably mediocre**. That is to say they are not beginners ("don't
> need
> > that wizard thank you very much") but also have no desire to become
> experts
> > ("manager pays me to write features not become maven expert").
> >
> > In maven it is very easy to get started. Put everything in magical
> > directories and magic happens. But lets say you forgot a command in
> maven?
> >
> > what does "mvn help" or "mvn -?" get the end user?
> >
> > Some goobly-gook about plugins or some very useless commandline
> arguments!
> >
> > Some basic things that are a pain to do in maven:
> >
> > 1. How do you copy a file from one directory to another just before a
> > war is constructed? I haven't a flipping clue!
> > 2. How do I have maven run my project... once again not a clue... ( or
> > just spit out a commandline that I can pipe to a .bat file)
> > 3. How about making sure all files needed are available so I can run
> > disconnected?
> > 4. How about being able to answer the question... why is this jar in
> > my build?
> > 5. How do I exclude a jar from my build no matter what dependency asks
> > for it?
> >
> > Not that there isn't a way to do it but keep in mind if it is harder to
> do
> > something in maven than in a shell script there is a problem! And
> telling me
> > to RTFM is just rude. I am working 14 hours a day and my kids want me to
> > spend time with them. Am I going to spend time learning maven or playing
> > with my 5-year-old?
> >
> > Telling me that I should be an expert in maven is just ridiculous. Being
> an
> > expert in maven is not going to make my company successful. Being an
> expert
> > in powerpoint has a better ROI than being a maven expert!
> >
> > So rather than spend time on a web site (which I rather not visit) --
> take
> > the time to make the simple, simple in maven, and to maven help out the
> > user.
> >
> > And for C*tsake make mvn help do something!
> >
> > I would suggest for starters look at what perforce's client does to help
> out
> > user. Until mvn has at least that level of help, I wouldn't even bother
> > spending the time on the website.
> >
> > As a *mediocre* user, I don't care how superior maven's plugin
> architecture
> > is... I am never going to write a plugin anyhow -- no time! I will use a
> > shell script first.
> >
> > Long live the *mediocre* user... and support them...
> >
> > -Pat
> >
> > P.S. sorry if I am a little harsh but I have lived this problem for too
> many
> > years in too many companies.
> >
> >
> > On 9/26/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> > >
> > > A common theme in the "maven is hard" thread is bad documentation and
> > > I'd like to explore this a little. For the sake of discussion, lets
> > > separate the plugin docs from the maven site. (Why? Because each
> plugin
> > > site is like it's own little world and some are good and some are bad.
> > > We can have that discussion after)
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
