maven-mvnd
maven-mvnd copied to clipboard
apache
Should not spawn a new daemon just for --help / --version
I was just building Quarkus with mvnd when I just wanted to check the mvnd options so I ran mvnd --help in another terminal.
I was surprised that a new daemon was spawned (other one was busy building Quarkus) just to print help, which seems a bit inefficient.
It is doable, although not a priority for myself. Feel free to send a PR. BTW, -v/--version is a similar case.
I think the most practical solution would be to have a text, properties or whichever other kind of a resource in mvnd-common or in mvnd-client that would contain all the necessary data for -h. Parts of that data is already available in org/mvndaemon/mvnd/common/Environment.javadoc.properties and in org/mvndaemon/mvnd/common/OptionType.javadoc.properties which are both generated by DocMojo. So the DocMojo would have to be enhanced to record all the missing data, most notably the result of org.apache.commons.cli.HelpFormatter.printHelp(PrintWriter, int, String, String, Options, int, int, String, boolean) that we now call on the Daemon side https://github.com/mvndaemon/mvnd/blob/master/daemon/src/main/java/org/apache/maven/cli/MvndHelpFormatter.java#L57
BTW, this will make the client tightly coupled to a specific Maven version. There was some discussion in the past where @gnodet said that he'd prefer to move towards a setup where a single client executable can spawn daemons using several distinct Maven versions. @gnodet, what do you think about the current proposal?
Right, I'd rather try to keep mvnd as much independent of the exact maven version in order to ease the migration or ideally, make it work with multiple versions.
However, given we redefine the MavenDaemonCli to override the default CLI already, I think that part is definitely dependent on the exact maven implementation and any change in the option supported by maven would require a change in that class, so I don't see the caching of the formatted help output as a problem.
