On Feb 4, 2008 5:14 PM, Dan Fabulich <[EMAIL PROTECTED]> wrote: > Jan Nielsen wrote: > > > Finding the definitive help information for a plugin should be > > absolutely trivial and built-in; having the CLI option which give the > > code-you-are-executing-right-now the ability to answer that question > > avoids the issues we have today with multiple sources for a plugin with > > different HTML usage information. > > Have you tried "mvn help:describe -Dplugin=nifty -Dmojo=nifty -Dfull"? I > think we already have what you want, but we've yet again failed to > document it adequately. (Try it with -Dplugin=compiler -Dmojo=compile.)
My point was useability; my first thought would not have been: mvn help:describe -Dplugin=nifty -Dmojo=nify -Dfull but something like: mvn nifty:help So, as you point out, all that would be needed is to hook up "mvn <plugin:help>" to "mvn help:describe -Dplugin=<plugin> -Dmojo=<all?> -Dfull". > > > And while I'm at it, and relatedly, whatever happened to "-G" to get me > > a list of all plugins??? > > I never used 1.x, but I don't think that makes sense any more. We could > certainly provide a list of all valid lifecycle phases (and we should do > so in the help plugin), since those are static and don't change. Yes! That would be terrific. And a list of the currently plugged in plugins for each lifecycle phase would be handy as well. > > http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html > > But as for finding plugins, it's better to search the Internet for that > sort of thing, rather than trying to turn the Maven core into an Internet > search engine for Maven plugins. (Similarly, wouldn't it be cool if you > could use a simple Maven command-line switch to search for jars you could > use in your project? Wait, no it wouldn't; that's what Google is for.) I understand your point, Dan. And while I agree somewhat with that, I like asking Eclipse to update and or search for new updates that are relevant to my version of Eclipse. I can use Google, and that's cool, but if Eclipse can help me filter all the irrelevant stuff that's even better - like, say, plugins which don't work on my version of the software. > > > And I might as well chuck in: why in the world do I need to do "mvn > > nifty:nifty" and not just "mvn nifty"? > > Because that way we don't have to guess whether you're trying to run a > goal or a lifecycle phase. "install" is a great example. Do you just > want to run the install:install goal, or did you want to run every > lifecycle phase up through the install phase? I agree; there is an issue with the plugins which are named the same as the static set of life-cycles, and that's unfortunate. But how about you make an exception for those that are not...which is the vast majority, no? So, really "mvn nifty" just means "run the nifty plugin's default goal", and "mvn install" just means run the "install" life-cycle, and "mvn install:help" means get me help on the install plugin...how would the average CLI user expect to get help on the "install" lifecycle? (Hint, it does not involve any -D switches or multiple arguments :-) > > -Dan > > > --------------------------------------------------------------------- > 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]
