Completion for phases, plugins and plugin goals

[mosabua]

Would it be possible to somehow get completion similar to https://github.com/juven/maven-bash-completion in mvnsh?

[jdillon]

basic completion of standard phases and common plugins is doable and should be fairly simple-ish. completion of options is also something I'm considering generally for all gshell; though mvn command is OpaqueArgument so it would need a customized impl of that; but also technically doable.

more advanced plugin ref may be more complex and require some tighter integration to allow the shell to resolve poms fully and could have undesired delays to build completion, so i'm not so sure this is viable; but the simple stuff very easy to do.

[mosabua]

The basic completion is all the bash one really does and imho its super useful for beginners (and lazy people like myself..)

[jdillon]

@mosabua fyi this is the start, nowhere near complete but for reference:

7d7f23b

Its also lossy for plugins that may have been changed; so I'm not gonna added to many of these yet.

[jdillon]

@mosabua minimal example of option completion, since mvnsh is OpaqueArguments d6f04fc

[mosabua]

Looks like that is not yet in the latest snapshot. If you want I can send a PR with more plugins and options.

[mosabua]

I built master from source and then saw the changes are in the refinement branch now.. will wait until thats merged and test then.

[jdillon]

ftr I think there is more work needed to make some of the options actually do the right thing; specifically those that are meant to take required arguments that are file references.

additionally I think will eventually want to have the shell become aware of the project structure too, but I don't want to get ahead of myself, but to be more functional will need to adjust the integration with maven to be a bit richer.

I ended up when refactoring from v2 just calling the MainCli to avoid duplicating all the option/argument config and also because otherwise there isn't a great simpler embeddable api; so I may re-explore that and see if maybe the maven folks might consider it for improvement maybe.

[jdillon]

@mosabua in terms of common plugin goals, wasn't quite sure what was needed and didn't really want to do that entire list that juven had. Also was considering maybe just making a way to expose this for users to actually configure for things they care about. Could be either a file in etc/ or maybe just another command to run and then mvnsh.rc to customize; dunno yet.

but if you have a list of what might be most common to use as default that would be helpful.

[mosabua]

I dont think it makes sense to restrict it to common use cases or so. Its really hard/impossible to know what people actually do. Just add them all unless there is a performance overhead. At a minimum we should add all plugins from Apache and maybe also all mojohaus ones. Beyond that maybe just popular ones or ones we get requests for.

But e.g. say the release, help and dependency plugin are all very useful ones to have.

And in terms of deeper integration with the actual project at hand.. sure .. but thats a later step than this simple and plain completion.

[jdillon]

probably more of an admin overhead to maintain that, can't even say if juvens set is sane wrt to plugin updates; and certainly if the plugin versions differ could complete non-existing goals; so I'm not a big fan of adding a huge mess of completion strings to support every possible completion that various folks might want.

for example juvens impl completes all those various skip options and a bunch more junk imo.

so much rather get a sane simple set and then expose the rest for folks to customize as they choose. maybe even a way to download plugins and then spit out a full completion config to cache or something too. a helper mvn plugin could probably do that pretty easily.

/me shrugs

[mosabua]

If its configurable by the user then that would alleviate the problem. In terms of lifecycle phases and Maven command line options I would just add all of them. There are not that many.

And for plugins, plugin goals and plugin parameters you could have a small default config set and ship a richer, optional set. Or just let users make and share those config sets separately.

[jdillon]

phases and cli will be complete, and I updated yesterday to actually use the CLIManager to get all the options directly, as well as lookup Lifecycle components and use those, so should be more in sync going forward w/o too much overhead to maintain.

Options still omitting those which take args as I need to figure out how to handle completion of those; but probably will sort that out soon.

[jeffjensen]

Yes, this is a great feature. The top completion for me is the module name for -rf.