Re: [Discuss] MPLUGIN-40
Jason van Zyl wrote: On 4-Feb-08, at 4:20 PM, Dan Fabulich wrote: Jason van Zyl wrote: I'm not saying the CLI is a good option. I think it's a bad option. Keep this out of the core. It's perfectly fine as a plugin. I'll throw in my two cents and point out that while I basically agree with this, I don't think the help plugin is adequately documented by the software right now. I agree, I think what Vincent made would be great where it was just auto generated and stuffed into the plugin so that mvn foo:help just works. It will take a while for all plugins to have this but I don't think it's that big a deal. It seems to me that putting a hook in core has considerable advantage over autogenerated copies of code in every plugin. Some plugins have such slow release cycles, or in some cases (e.g. xdoclet-maven-plugin) are almost dead, but still used. So, if a plugin has to rebuilt to integrate the feature, some plugins are never going to get the feature. As a result the user experience will be patchy, with the beginner's impression being that the help command spuriously fails in some cases for no apparent reason. The problem would be ongoing, too - after any update to the autogenerated code, stale versions will linger for a long time. A special syntax in the core CLI mapping onto a help plugin invocation would nicely dodge the whole re-release the world issue whilst still allowing the implementation of the help display to be updated independently of core. What's the disadvantage to that? Max. signature.asc Description: OpenPGP digital signature
Re: [Discuss] MPLUGIN-40
On 5-Feb-08, at 7:44 AM, Max Bowsher wrote: Jason van Zyl wrote: On 4-Feb-08, at 4:20 PM, Dan Fabulich wrote: Jason van Zyl wrote: I'm not saying the CLI is a good option. I think it's a bad option. Keep this out of the core. It's perfectly fine as a plugin. I'll throw in my two cents and point out that while I basically agree with this, I don't think the help plugin is adequately documented by the software right now. I agree, I think what Vincent made would be great where it was just auto generated and stuffed into the plugin so that mvn foo:help just works. It will take a while for all plugins to have this but I don't think it's that big a deal. It seems to me that putting a hook in core has considerable advantage over autogenerated copies of code in every plugin. Some plugins have such slow release cycles, or in some cases (e.g. xdoclet-maven-plugin) are almost dead, but still used. So, if a plugin has to rebuilt to integrate the feature, some plugins are never going to get the feature. As a result the user experience will be patchy, with the beginner's impression being that the help command spuriously fails in some cases for no apparent reason. So users who decide to stay on Maven 2.0.8 will not get it at all until they upgrade which in many shops would be a year, or more. There are advantages and disadvantages. The primary advantages of keeping it out of the core is that improvements to the help mechanism are not coupled to releases of the core, and we're not going to bind ourselves to a specific version of the API. It is possible to isolate the execution of the a plugin for a particular version of the plugin API. In the short term we can use mvn foo:help, and if we see a way of putting it cleanly in the core, or it is such a horrendous problem for users (which I don't honestly see being the case) then we can map any help goal to a standard mechanism if the plugin has not already implemented. The tool we use will have its own dependencies, its own API and those things are always hard to wind into the core. I would like to see it work as a first step on a few plugins that use it first, and then look at making it a core feature if that is necessary. Instead of just jamming it into the core. The problem would be ongoing, too - after any update to the autogenerated code, stale versions will linger for a long time. A special syntax in the core CLI mapping onto a help plugin invocation would nicely dodge the whole re-release the world issue whilst still allowing the implementation of the help display to be updated independently of core. What's the disadvantage to that? Max. Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discuss] MPLUGIN-40
-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
Re: [Discuss] MPLUGIN-40
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again, I wrote: 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. Maybe I should have read the thread properly from the beginning. My suggested improvement to plugin-plugin seems to be what has already been done to fix the problem for the long run. However the further suggestion might solve the problem now and could be kicked out in maven 3.x or whenever each plugin does have a help goal. The only thing is that it needs to be done in maven-core and can NOT be made available via a plugin release but only by a new maven version explicitly updated by the users. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHqM7mmPuec2Dcv/8RAi59AJ9LUAFdnnfH183QVPq0ic1jljvIGgCghpRa 2T0HEfVYe+/4/ggf01JfF2U= =bIDc -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discuss] MPLUGIN-40
On 4-Feb-08, at 4:09 AM, Vincent Siveton wrote: Hi, 2008/2/3, Jason van Zyl [EMAIL PROTECTED]: I think keeping this out of the core, be that the lifecycle executor or the CLI would be a far better option. Agree for CLI. I'm not saying the CLI is a good option. I think it's a bad option. Keep this out of the core. It's perfectly fine as a plugin. The core and the CLI calling to a wrapper for something housed in a plugin is not a good idea. Generate it as part of the new tools, promote it and it will get picked up in new plugin releases. Vincent, just to be clear you have taken the logic that already exists in the help plugin? More wrapped logic from PluginXdocGenerator. Cheers, Vincent On 3-Feb-08, at 3:17 PM, Brett Porter wrote: Something like mvn -H idea:idea or mvn -H idea which is akin to what Subversion has, for example. this would allow the CLI to translate to the appropriate help:describe goal and then exit, which is pretty clean, as compared to modifying the lifecycle executor. - Brett On 04/02/2008, at 10:13 AM, Vincent Siveton wrote: Hi Brett, What do you propose for cmd line switch? Personally, I am fine with mvn my-plugin:help which seems more common. A lot of tools (all?) have an help option. Cheers, Vincent 2008/2/3, Brett Porter [EMAIL PROTECTED]: Would a different lifecycle or command line switch be more intuitive than this? On 04/02/2008, at 9:55 AM, Vincent Siveton wrote: Hi, I realize that the fix for MPLUGIN-40 (All plugins should by default have an auto-generated goal 'help') is definitely *not* intuitive for the end user. Background: I created a plugin-plugin goal which generates an Help mojo. This generated mojo just displays the goals and their description/parameters for a given plugin project. Since it is a goal inside the maven-plugin-plugin, we need to release it and *all* plugins to make available this new feature (it could take a time ;) ). I proposed another approach: modify the DefaultLifecycleExecutor to handle this particular goal. So we could call mvn idea:help to display all available idea goals and mvn idea:toto will throw an exception by displaying the help. Pro: more easy for the end user and works for all plugins Con: just available in mvn 2.0.9+ WDYT? Vincent - 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] - 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] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - 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] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Three people can keep a secret provided two of them are dead. -- Unknown - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discuss] MPLUGIN-40
Hi, 2008/2/3, Brett Porter [EMAIL PROTECTED]: Something like mvn -H idea:idea or mvn -H idea I didn't think about this kind of CLI option before! It sounds good for the end user. which is akin to what Subversion has, for example. this would allow the CLI to translate to the appropriate help:describe goal and then exit, which is pretty clean, as compared to modifying the lifecycle executor. Yeah it was the goal of my question :) I felt uncomfortable to modify it. Cheers, Vincent - Brett On 04/02/2008, at 10:13 AM, Vincent Siveton wrote: Hi Brett, What do you propose for cmd line switch? Personally, I am fine with mvn my-plugin:help which seems more common. A lot of tools (all?) have an help option. Cheers, Vincent 2008/2/3, Brett Porter [EMAIL PROTECTED]: Would a different lifecycle or command line switch be more intuitive than this? On 04/02/2008, at 9:55 AM, Vincent Siveton wrote: Hi, I realize that the fix for MPLUGIN-40 (All plugins should by default have an auto-generated goal 'help') is definitely *not* intuitive for the end user. Background: I created a plugin-plugin goal which generates an Help mojo. This generated mojo just displays the goals and their description/parameters for a given plugin project. Since it is a goal inside the maven-plugin-plugin, we need to release it and *all* plugins to make available this new feature (it could take a time ;) ). I proposed another approach: modify the DefaultLifecycleExecutor to handle this particular goal. So we could call mvn idea:help to display all available idea goals and mvn idea:toto will throw an exception by displaying the help. Pro: more easy for the end user and works for all plugins Con: just available in mvn 2.0.9+ WDYT? Vincent - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discuss] MPLUGIN-40
Hi, 2008/2/3, Jason van Zyl [EMAIL PROTECTED]: I think keeping this out of the core, be that the lifecycle executor or the CLI would be a far better option. Agree for CLI. Vincent, just to be clear you have taken the logic that already exists in the help plugin? More wrapped logic from PluginXdocGenerator. Cheers, Vincent On 3-Feb-08, at 3:17 PM, Brett Porter wrote: Something like mvn -H idea:idea or mvn -H idea which is akin to what Subversion has, for example. this would allow the CLI to translate to the appropriate help:describe goal and then exit, which is pretty clean, as compared to modifying the lifecycle executor. - Brett On 04/02/2008, at 10:13 AM, Vincent Siveton wrote: Hi Brett, What do you propose for cmd line switch? Personally, I am fine with mvn my-plugin:help which seems more common. A lot of tools (all?) have an help option. Cheers, Vincent 2008/2/3, Brett Porter [EMAIL PROTECTED]: Would a different lifecycle or command line switch be more intuitive than this? On 04/02/2008, at 9:55 AM, Vincent Siveton wrote: Hi, I realize that the fix for MPLUGIN-40 (All plugins should by default have an auto-generated goal 'help') is definitely *not* intuitive for the end user. Background: I created a plugin-plugin goal which generates an Help mojo. This generated mojo just displays the goals and their description/parameters for a given plugin project. Since it is a goal inside the maven-plugin-plugin, we need to release it and *all* plugins to make available this new feature (it could take a time ;) ). I proposed another approach: modify the DefaultLifecycleExecutor to handle this particular goal. So we could call mvn idea:help to display all available idea goals and mvn idea:toto will throw an exception by displaying the help. Pro: more easy for the end user and works for all plugins Con: just available in mvn 2.0.9+ WDYT? Vincent - 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] - 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] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - 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]
Re: [Discuss] MPLUGIN-40
FWIW, I (and probably 99.9% of the Maven user-base) have desired just this kind of option for plugins for a l o o o n g time. Something like: mvn nifty help mvn nifty -h mvn nifty --help mvn nifty:help mvn nifty:option mvn nifty and if you do: mvn nifty:invalid you just get the help (where nifty is any plugin; any, as in for all plugins...if the plugin can be downloaded, help is there). That's pretty canonical CLI behavior. I don't know whether that's something that requires a modification to the core of Maven, or not, and I really don't care. It's a huge dis-service to all users to not have this available, thereby forcing the user to chase down the web-page for every plugin they have an interest in. 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. And while I'm at it, and relatedly, whatever happened to -G to get me a list of all plugins??? I know it ain't easy, but how about giving me a list of all the names of the plugins found in the configured repositories when I do mvn -G, or mvn plugin:help, or mvn plugin:list, whatever. Cache the result in the repositories if you need to, but make it easy for the user to find and use plugins. And I might as well chuck in: why in the world do I need to do mvn nifty:nifty and not just mvn nifty? Yes; a plugin can have more than one goal - that's great; but if I do mvn nifty it just means mvn nifty:nifty and if I do mvn nifty:wizbang well, then that's the wizbang goal of the nifty plugin. -Jan On Feb 4, 2008 5:09 AM, Vincent Siveton [EMAIL PROTECTED] wrote: Hi, 2008/2/3, Jason van Zyl [EMAIL PROTECTED]: I think keeping this out of the core, be that the lifecycle executor or the CLI would be a far better option. Agree for CLI. Vincent, just to be clear you have taken the logic that already exists in the help plugin? More wrapped logic from PluginXdocGenerator. Cheers, Vincent On 3-Feb-08, at 3:17 PM, Brett Porter wrote: Something like mvn -H idea:idea or mvn -H idea which is akin to what Subversion has, for example. this would allow the CLI to translate to the appropriate help:describe goal and then exit, which is pretty clean, as compared to modifying the lifecycle executor. - Brett On 04/02/2008, at 10:13 AM, Vincent Siveton wrote: Hi Brett, What do you propose for cmd line switch? Personally, I am fine with mvn my-plugin:help which seems more common. A lot of tools (all?) have an help option. Cheers, Vincent 2008/2/3, Brett Porter [EMAIL PROTECTED]: Would a different lifecycle or command line switch be more intuitive than this? On 04/02/2008, at 9:55 AM, Vincent Siveton wrote: Hi, I realize that the fix for MPLUGIN-40 (All plugins should by default have an auto-generated goal 'help') is definitely *not* intuitive for the end user. Background: I created a plugin-plugin goal which generates an Help mojo. This generated mojo just displays the goals and their description/parameters for a given plugin project. Since it is a goal inside the maven-plugin-plugin, we need to release it and *all* plugins to make available this new feature (it could take a time ;) ). I proposed another approach: modify the DefaultLifecycleExecutor to handle this particular goal. So we could call mvn idea:help to display all available idea goals and mvn idea:toto will throw an exception by displaying the help. Pro: more easy for the end user and works for all plugins Con: just available in mvn 2.0.9+ WDYT? Vincent - 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] - 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] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discuss] MPLUGIN-40
On 4-Feb-08, at 4:20 PM, Dan Fabulich wrote: Jason van Zyl wrote: I'm not saying the CLI is a good option. I think it's a bad option. Keep this out of the core. It's perfectly fine as a plugin. I'll throw in my two cents and point out that while I basically agree with this, I don't think the help plugin is adequately documented by the software right now. I agree, I think what Vincent made would be great where it was just auto generated and stuffed into the plugin so that mvn foo:help just works. It will take a while for all plugins to have this but I don't think it's that big a deal. That is, I think some other command line tools (notably svn) are pretty easy to learn using just the command line. You start with svn help; it gives you a list of commands you can use, and suggests that you type svn help subcommand for more help on a specific command. Right now, mvn --help gives you a list of command line switches, but no commands to run, not even a suggestion that you might want to use the help plugin. It would be easy to modify the --help text to mention the help plugin, and maybe that's enough. But I think we could at least make a very simple help lifecycle phase that's bound to help:describe by default. That would make mvn help a synonym for mvn help:describe . I think this would be pretty useful if we also did some more work on the Maven help plugin, which is surprisingly tricky to use. I just filed about half a dozen new JIRA issues on it today that suggest some ways it could be easier to use and work with. For example, I could imagine the user typing mvn help:describe (or, eventually, just mvn help) and getting a nice description of how the help plugin works. Then they could use that to learn more about Maven, perhaps investigating a particular plugin goal with mvn help -Dcmd=idea:idea, or get a list of goals in a plugin with mvn help -Dplugin=idea, or learn about the lifecycle with mvn help:lifecycle. The core and the CLI calling to a wrapper for something housed in a plugin is not a good idea. +1. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discuss] MPLUGIN-40
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.) 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. 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.) 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? -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discuss] MPLUGIN-40
On 4-Feb-08, at 3:37 PM, Jan Nielsen wrote: FWIW, I (and probably 99.9% of the Maven user-base) have desired just this kind of option for plugins for a l o o o n g time. Something like: mvn nifty help mvn nifty -h mvn nifty --help mvn nifty:help This one is fine. As it doesn't need to go into the CLI, it's just part of the plugin. mvn nifty:option mvn nifty and if you do: mvn nifty:invalid you just get the help (where nifty is any plugin; any, as in for all plugins...if the plugin can be downloaded, help is there). That's pretty canonical CLI behavior. I think everyone could live with the mvn foo:help. I don't know whether that's something that requires a modification to the core of Maven, or not, and I really don't care. It's a huge dis-service to all users to not have this available, thereby forcing the user to chase down the web-page for every plugin they have an interest in. 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. And while I'm at it, and relatedly, whatever happened to -G to get me a list of all plugins??? I know it ain't easy, but how about giving me a list of all the names of the plugins found in the configured repositories when I do mvn -G, or mvn plugin:help, or mvn plugin:list, whatever. Cache the result in the repositories if you need to, but make it easy for the user to find and use plugins. And I might as well chuck in: why in the world do I need to do mvn nifty:nifty and not just mvn nifty? Yes; a plugin can have more than one goal - that's great; but if I do mvn nifty it just means mvn nifty:nifty and if I do mvn nifty:wizbang well, then that's the wizbang goal of the nifty plugin. -Jan On Feb 4, 2008 5:09 AM, Vincent Siveton [EMAIL PROTECTED] wrote: Hi, 2008/2/3, Jason van Zyl [EMAIL PROTECTED]: I think keeping this out of the core, be that the lifecycle executor or the CLI would be a far better option. Agree for CLI. Vincent, just to be clear you have taken the logic that already exists in the help plugin? More wrapped logic from PluginXdocGenerator. Cheers, Vincent On 3-Feb-08, at 3:17 PM, Brett Porter wrote: Something like mvn -H idea:idea or mvn -H idea which is akin to what Subversion has, for example. this would allow the CLI to translate to the appropriate help:describe goal and then exit, which is pretty clean, as compared to modifying the lifecycle executor. - Brett On 04/02/2008, at 10:13 AM, Vincent Siveton wrote: Hi Brett, What do you propose for cmd line switch? Personally, I am fine with mvn my-plugin:help which seems more common. A lot of tools (all?) have an help option. Cheers, Vincent 2008/2/3, Brett Porter [EMAIL PROTECTED]: Would a different lifecycle or command line switch be more intuitive than this? On 04/02/2008, at 9:55 AM, Vincent Siveton wrote: Hi, I realize that the fix for MPLUGIN-40 (All plugins should by default have an auto-generated goal 'help') is definitely *not* intuitive for the end user. Background: I created a plugin-plugin goal which generates an Help mojo. This generated mojo just displays the goals and their description/parameters for a given plugin project. Since it is a goal inside the maven-plugin-plugin, we need to release it and *all* plugins to make available this new feature (it could take a time ;) ). I proposed another approach: modify the DefaultLifecycleExecutor to handle this particular goal. So we could call mvn idea:help to display all available idea goals and mvn idea:toto will throw an exception by displaying the help. Pro: more easy for the end user and works for all plugins Con: just available in mvn 2.0.9+ WDYT? Vincent - 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] - 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] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discuss] MPLUGIN-40
Jason van Zyl wrote: I'm not saying the CLI is a good option. I think it's a bad option. Keep this out of the core. It's perfectly fine as a plugin. I'll throw in my two cents and point out that while I basically agree with this, I don't think the help plugin is adequately documented by the software right now. That is, I think some other command line tools (notably svn) are pretty easy to learn using just the command line. You start with svn help; it gives you a list of commands you can use, and suggests that you type svn help subcommand for more help on a specific command. Right now, mvn --help gives you a list of command line switches, but no commands to run, not even a suggestion that you might want to use the help plugin. It would be easy to modify the --help text to mention the help plugin, and maybe that's enough. But I think we could at least make a very simple help lifecycle phase that's bound to help:describe by default. That would make mvn help a synonym for mvn help:describe. I think this would be pretty useful if we also did some more work on the Maven help plugin, which is surprisingly tricky to use. I just filed about half a dozen new JIRA issues on it today that suggest some ways it could be easier to use and work with. For example, I could imagine the user typing mvn help:describe (or, eventually, just mvn help) and getting a nice description of how the help plugin works. Then they could use that to learn more about Maven, perhaps investigating a particular plugin goal with mvn help -Dcmd=idea:idea, or get a list of goals in a plugin with mvn help -Dplugin=idea, or learn about the lifecycle with mvn help:lifecycle. The core and the CLI calling to a wrapper for something housed in a plugin is not a good idea. +1. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discuss] MPLUGIN-40
On Feb 4, 2008, at 6:14 PM, Dan Fabulich 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.) I'm sorry, hold on... starting stopwatch mvn help:describe - Dplugin=nifty -Dmojo=nifty -Dfull - alright, I type fast, but that took me 10 seconds. Then I hit enter and a whole *crapload* of information zoomed past. Ok, CTRL-R, mvn, adding a | less. Ok, for something like help:describe, I'm looking at eight or nine pages of sleep inducing variable names. I'm serious the help plugin hurts, go back to what Jason said about svn doing a better job. 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. 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.) Dan, can I quote you on It's better to search the Internet for that sort of thing the next time I have to defend Maven to some end-user who is absolutely enraged by the fact that they've had to spend the last fourteen hours trying to track down the reason why the dependency plugin they have installed doesn't support the tree goal even though the documentation on the Maven site tells them to run it (Hint: they don't have the right version) No one is saying they want Maven to be the Internet Search Engine for plugins. Maybe someone is saying, what we have now isn't adequate.Seconded. 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? Makes sense.But, wait, in that help:describe, you didn't call it a goal, the property was a mojo?I guess what Mavenland has to get over is that users don't know what a Mojo is? They shouldn't be expected to know what a Mojo is, you should be able to use Maven without knowing very much about it. -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]
Re: [Discuss] MPLUGIN-40
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]
Re: [Discuss] MPLUGIN-40
Tim O'Brien wrote: I'm sorry, hold on... starting stopwatch mvn help:describe -Dplugin=nifty -Dmojo=nifty -Dfull - alright, I type fast, but that took me 10 seconds. Then I hit enter and a whole *crapload* of information zoomed past. Ok, CTRL-R, mvn, adding a | less. Ok, for something like help:describe, I'm looking at eight or nine pages of sleep inducing variable names. Slow down, we agree more than we disagree. That's why I filed a bunch of bugs against MPH today: http://tinyurl.com/2c4j42 In particular, I think MPH-31 and MPH-32 would be good fixes, and don't require weird changes to core. I'd prefer you'd typed mvn help -Dcmd=nifty:nifty, and that mvn help explained how that works. I'm serious the help plugin hurts, go back to what Jason said about svn doing a better job. (Didn't I say that?) I'm not saying that the help plugin is perfect; I'm saying that we don't need to re-invent the wheel or hack the CLI to make this feature work, and that if you want to use it, you can start doing so right now. 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. Dan, can I quote you on It's better to search the Internet for that sort of thing the next time I have to defend Maven to some end-user who is absolutely enraged by the fact that they've had to spend the last fourteen hours trying to track down the reason why the dependency plugin they have installed doesn't support the tree goal even though the documentation on the Maven site tells them to run it (Hint: they don't have the right version) Version diagnosis is very different from finding plugins to use. It IS better to search the Internet to find plugins, which is what the -G switch is all about. (It tells you about all plugins available everywhere, not just the ones you've got installed.) Searching the Internet isn't better to diagnose version problems, but then, -G wouldn't have helped that either. In fact, the help plugin is a pretty good way of diagnosing versions, or at least starting to. mvn help:describe -Dplugin=dependency -Dmedium will tell you what you can do with the dependency plugin you've got installed and, prominently, what version you're using. Annoyed by those -Dfull and -Dmedium flags? Me, too... that's MPH-31, MPH-32, and MPH-35. No one is saying they want Maven to be the Internet Search Engine for plugins. Maybe someone is saying, what we have now isn't adequate. Seconded. We agree again! Makes sense. But, wait, in that help:describe, you didn't call it a goal, the property was a mojo? Yeah, that's why I already filed MPH-33 earlier today. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discuss] MPLUGIN-40
On Feb 4, 2008, at 8:49 PM, Dan Fabulich wrote: Tim O'Brien wrote: I'm sorry, hold on... starting stopwatch mvn help:describe - Dplugin=nifty -Dmojo=nifty -Dfull - alright, I type fast, but that took me 10 seconds. Then I hit enter and a whole *crapload* of information zoomed past. Ok, CTRL-R, mvn, adding a | less. Ok, for something like help:describe, I'm looking at eight or nine pages of sleep inducing variable names. Slow down, we agree more than we disagree. That's why I filed a bunch of bugs against MPH today: http://tinyurl.com/2c4j42 In particular, I think MPH-31 and MPH-32 would be good fixes, and don't require weird changes to core. I'd prefer you'd typed mvn help -Dcmd=nifty:nifty, and that mvn help explained how that works. I'm serious the help plugin hurts, go back to what Jason said about svn doing a better job. (Didn't I say that?) I'm not saying that the help plugin is perfect; I'm saying that we don't need to re-invent the wheel or hack the CLI to make this feature work, and that if you want to use it, you can start doing so right now. Well I think it would help to make it a bit more accessible. All that: mvn help:describe -Dplugin=blah -Dmojo=foo -Dfull Should likely be changed to something easier to type: mvn-help dependency or mvn-help ant:run mvn-help -l lists all plugins No? Yes? 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. Dan, can I quote you on It's better to search the Internet for that sort of thing the next time I have to defend Maven to some end-user who is absolutely enraged by the fact that they've had to spend the last fourteen hours trying to track down the reason why the dependency plugin they have installed doesn't support the tree goal even though the documentation on the Maven site tells them to run it (Hint: they don't have the right version) Version diagnosis is very different from finding plugins to use. It IS better to search the Internet to find plugins, which is what the - G switch is all about. (It tells you about all plugins available everywhere, not just the ones you've got installed.) Searching the Internet isn't better to diagnose version problems, but then, -G wouldn't have helped that either. I guess I disagree here because I believe the following statements to be true: mojo is something of a horror (it's getting a little better), plugins on the Maven site are often dev versions, the future of the success of Maven is for plugin development to become very decentralized (see Springer's Docbkx, and the Israfil Flex plugin) I think a simple tool, packaged with Maven that knows of some plugin groupIds. Would be a great thing. Run it, it lists all the plugins it knows about, you can see information about them.It's like gem for Maven.. In fact, the help plugin is a pretty good way of diagnosing versions, or at least starting to. mvn help:describe - Dplugin=dependency -Dmedium will tell you what you can do with the dependency plugin you've got installed and, prominently, what version you're using. Annoyed by those -Dfull and -Dmedium flags? Me, too... that's MPH-31, MPH-32, and MPH-35. No one is saying they want Maven to be the Internet Search Engine for plugins. Maybe someone is saying, what we have now isn't adequate. Seconded. We agree again! Alright, Dan, let's do it. Let me know how I can help. Makes sense. But, wait, in that help:describe, you didn't call it a goal, the property was a mojo? Yeah, that's why I already filed MPH-33 earlier today. I dig. -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]
Re: [Discuss] MPLUGIN-40
Hi Brett, What do you propose for cmd line switch? Personally, I am fine with mvn my-plugin:help which seems more common. A lot of tools (all?) have an help option. Cheers, Vincent 2008/2/3, Brett Porter [EMAIL PROTECTED]: Would a different lifecycle or command line switch be more intuitive than this? On 04/02/2008, at 9:55 AM, Vincent Siveton wrote: Hi, I realize that the fix for MPLUGIN-40 (All plugins should by default have an auto-generated goal 'help') is definitely *not* intuitive for the end user. Background: I created a plugin-plugin goal which generates an Help mojo. This generated mojo just displays the goals and their description/parameters for a given plugin project. Since it is a goal inside the maven-plugin-plugin, we need to release it and *all* plugins to make available this new feature (it could take a time ;) ). I proposed another approach: modify the DefaultLifecycleExecutor to handle this particular goal. So we could call mvn idea:help to display all available idea goals and mvn idea:toto will throw an exception by displaying the help. Pro: more easy for the end user and works for all plugins Con: just available in mvn 2.0.9+ WDYT? Vincent - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discuss] MPLUGIN-40
Something like mvn -H idea:idea or mvn -H idea which is akin to what Subversion has, for example. this would allow the CLI to translate to the appropriate help:describe goal and then exit, which is pretty clean, as compared to modifying the lifecycle executor. - Brett On 04/02/2008, at 10:13 AM, Vincent Siveton wrote: Hi Brett, What do you propose for cmd line switch? Personally, I am fine with mvn my-plugin:help which seems more common. A lot of tools (all?) have an help option. Cheers, Vincent 2008/2/3, Brett Porter [EMAIL PROTECTED]: Would a different lifecycle or command line switch be more intuitive than this? On 04/02/2008, at 9:55 AM, Vincent Siveton wrote: Hi, I realize that the fix for MPLUGIN-40 (All plugins should by default have an auto-generated goal 'help') is definitely *not* intuitive for the end user. Background: I created a plugin-plugin goal which generates an Help mojo. This generated mojo just displays the goals and their description/parameters for a given plugin project. Since it is a goal inside the maven-plugin-plugin, we need to release it and *all* plugins to make available this new feature (it could take a time ;) ). I proposed another approach: modify the DefaultLifecycleExecutor to handle this particular goal. So we could call mvn idea:help to display all available idea goals and mvn idea:toto will throw an exception by displaying the help. Pro: more easy for the end user and works for all plugins Con: just available in mvn 2.0.9+ WDYT? Vincent - 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] - 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]
Re: [Discuss] MPLUGIN-40
Would a different lifecycle or command line switch be more intuitive than this? On 04/02/2008, at 9:55 AM, Vincent Siveton wrote: Hi, I realize that the fix for MPLUGIN-40 (All plugins should by default have an auto-generated goal 'help') is definitely *not* intuitive for the end user. Background: I created a plugin-plugin goal which generates an Help mojo. This generated mojo just displays the goals and their description/parameters for a given plugin project. Since it is a goal inside the maven-plugin-plugin, we need to release it and *all* plugins to make available this new feature (it could take a time ;) ). I proposed another approach: modify the DefaultLifecycleExecutor to handle this particular goal. So we could call mvn idea:help to display all available idea goals and mvn idea:toto will throw an exception by displaying the help. Pro: more easy for the end user and works for all plugins Con: just available in mvn 2.0.9+ WDYT? Vincent - 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]
Re: [Discuss] MPLUGIN-40
I think keeping this out of the core, be that the lifecycle executor or the CLI would be a far better option. Vincent, just to be clear you have taken the logic that already exists in the help plugin? On 3-Feb-08, at 3:17 PM, Brett Porter wrote: Something like mvn -H idea:idea or mvn -H idea which is akin to what Subversion has, for example. this would allow the CLI to translate to the appropriate help:describe goal and then exit, which is pretty clean, as compared to modifying the lifecycle executor. - Brett On 04/02/2008, at 10:13 AM, Vincent Siveton wrote: Hi Brett, What do you propose for cmd line switch? Personally, I am fine with mvn my-plugin:help which seems more common. A lot of tools (all?) have an help option. Cheers, Vincent 2008/2/3, Brett Porter [EMAIL PROTECTED]: Would a different lifecycle or command line switch be more intuitive than this? On 04/02/2008, at 9:55 AM, Vincent Siveton wrote: Hi, I realize that the fix for MPLUGIN-40 (All plugins should by default have an auto-generated goal 'help') is definitely *not* intuitive for the end user. Background: I created a plugin-plugin goal which generates an Help mojo. This generated mojo just displays the goals and their description/parameters for a given plugin project. Since it is a goal inside the maven-plugin-plugin, we need to release it and *all* plugins to make available this new feature (it could take a time ;) ). I proposed another approach: modify the DefaultLifecycleExecutor to handle this particular goal. So we could call mvn idea:help to display all available idea goals and mvn idea:toto will throw an exception by displaying the help. Pro: more easy for the end user and works for all plugins Con: just available in mvn 2.0.9+ WDYT? Vincent - 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] - 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] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discuss] MPLUGIN-40
On 3-Feb-08, at 2:55 PM, Vincent Siveton wrote: Hi, I realize that the fix for MPLUGIN-40 (All plugins should by default have an auto-generated goal 'help') is definitely *not* intuitive for the end user. Background: I created a plugin-plugin goal which generates an Help mojo. This generated mojo just displays the goals and their description/parameters for a given plugin project. Since it is a goal inside the maven-plugin-plugin, we need to release it and *all* plugins to make available this new feature (it could take a time ;) ). I don't see a problem with that. I proposed another approach: modify the DefaultLifecycleExecutor to handle this particular goal. No. Don't bind special logic for plugins internally. It's much easier to release a tool in an external toolchain or fix a plugin. The help plugin already does this doesn't it? Specify a particular plugin and it gives you the goals. Did you take this logic and move it to the plugin plugin? So we could call mvn idea:help to display all available idea goals and mvn idea:toto will throw an exception by displaying the help. Pro: more easy for the end user and works for all plugins Con: just available in mvn 2.0.9+ WDYT? Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
