Make client thin

[cstamas]

Currently there is some heavy logic in client, but IMHO it is superfluous.
Instead, make client thin as possible:

• it should collect all maven config and create "seed" (ie. by hashing these things opaquely)
• based on "seed" select (or start) a daemon
• it should collect CWD and CLI params and send those those to daemon
• sit and wait, and let m39, m40, mXX decide what it likes or dislikes out of params

[gnodet]

The goal is to fully respect what the user environment as usually loaded by maven.

The compatibility is defined by two simple things:

• the JVM path (a String)
• a list of options (List<String>)
  The list of options is known as discriminating options. Those are options that actually make the daemon different and thus needs a different daemon.
  So we can definitely compute a hash of those strings, but that won't really simplify things, as the tricky part is to list and gather those options, not to compare those. See

  maven-mvnd/common/src/main/java/org/mvndaemon/mvnd/common/DaemonCompatibilitySpec.java

  Lines 33 to 34 in a14a1eb

  	private final Path javaHome;
  	private final List<String> options;

For point #3, I think that's what the client roughly does. Why would that be different ? Here's what is sent to the daemon:

maven-mvnd/common/src/main/java/org/mvndaemon/mvnd/common/Message.java

Lines 328 to 331 in 2b8076d

	final List<String> args;
	final String workingDir;
	final String projectDir;
	final Map<String, String> env;

Not sure to understand #4...

[cstamas]

Point 4 is about "client should not try to interpret ANY command, just pass it to daemon and let it interpret (and return any error if params are bad)". This way the client could be even "universal", same client could work for mvnd 1 and mvnd 2 (maybe not, but this is the idea). So make client "thin" in a way it does very same thing always, is unaware of backend, is just a mailman (between user/terminal and backend).

[gnodet]

Point 4 is about "client should not try to interpret ANY command, just pass it to daemon and let it interpret (and return any error if params are bad)". This way the client could be even "universal", same client could work for mvnd 1 and mvnd 2 (maybe not, but this is the idea). So make client "thin" in a way it does very same thing always, is unaware of backend, is just a mailman (between user/terminal and backend).

That can be done as long as the option is "compatible" between daemons. As soon as option cannot be changed between runs (such as JVM options), the client must select an appropriate option, so it needs to understand those. Also, options that affects the display have to be well understood and handled on the client, as that's the one displaying everything. In addition, there are a few mvnd specific options that need to be handled.
All in all, if you can point to any code we can get rid of, I'm all for it, but I don't see, at first glance, any code which sounds irrelevant.