-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, >>> 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". Maybe we would need a more specific syntax in this case because some plugin might supply a help mojo and rewriting this as suggested and overruling an existing help-mojo would be quite confusing. But anyhow your suggestion is well worth a thought.
I would prefer that if maven builds a plugin that has no goal "help" already, then it auto-generates one in about the same way as it does when generating the goal-documentation for the site. Then each plugin would have (in future versions) a help mojo and "mvn <plugin>:help" would work as expected. Additionally a plugin can provide an individual help goal that produces a more user-friendly hand-written help page. Third if "mvn <plugin>:help" is called and "<plugin>" points to a valid plugin that has no goal "help" then maven could rewrite this command as suggested via help:describe. > >>> 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. I do NOT agree with this. Eclise does NOT know by itself about external plugins. It can update them if they are registered but you still have to google to find a subversion plugin, checkstyle plugin, emma plugin, findbugs plugin, etc. Besides this mechanism of eclipse totaly sucks!!! Eclipse shows the "Display-Names" of available plugins from update sites. If you select one and it has a dependency, the technical name of the dependency is shown. Sometimes I get totally lost in how to find a combination that is valid to be installed. They could learn a lot from maven about dependency management. The placement and configuration somewhere in help is totally misplaced, etc. Not really a good example to point out if you ask me... > >>> 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 I agree! We should NOT be to academic here. There will always be users that will not and even do not want to understand the details about the difference of the lifecycle and the plugin. Naive users just try "mvn eclispe" like "mvn install" and in both cases it is clear what the user really wants to do. If you type "mvn <plugin>" and "<plugin>" is no lifecycle phase, maven could behave as if the user typed "mvn <plugin>:<plugin>". We would not even loose too much control about lifecycle names because <plugin> is either fully qualified or it points to org.apache.maven.plugins:maven-<plugin>-plugin or to org.codehaus.mojo:<plugin>-maven-plugin. We should have an eye of what gets released from there anyways... > , 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 :-) That is a different point, but worth a thought. However if "mvn --help" explanes the lifecycles, that is fine and if the install-plugin has a help mojo, this could explain the plugin and the phase. > > Take care Jörg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHqMvtmPuec2Dcv/8RAs4eAKCEO+rQnBu1sXXsTPKQ3t/e3gH82gCghCyB i0DUU6ghtzFSMSeiTkhc0eA= =68RD -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
