Support for --module-path dependencies for compatibility with javafx 9+

[cmhulbert]

In more recent versions of Javafx, the javafx libraries are provided using the module system which was introduced in Java 9. Even when using these dependencies from a project which does not use the module system, it is still required to add the javafx jar files to the --module-path instead of the --classpath.

I've proposed an additional optional parameter, --module-dependencies which accepts a list of artifact coordinates, of the form groupId:artifactId:version[:classifier]. When resolving dependencies, jgo will check if any of the discovered dependencies are located in the module-dependencies list. If so, it will place these jar files in a subdirectory of the cache_dir workspace, named modules. This directory will then be specified as a jvm argument as --module-path ${workspace}/modules.

This is not intended to provide full java module system support, but is intended to provide a mechanism for using dependencies which have been built for use with the module system. This also does not handle all of the possible jvm arguments for module configuration, only the --module-path, since the location of the jar files are otherwise unknown to the user when calling jgo. Other Module specific arguments should still be passed into jgo the same as any other JVM argument.

[bogovicj]

@hinerm and @ctrueden, meet Caleb (@cmhulbert) our new developer.

Caleb has taken over paintera development and will be a big part of saalfeldlab projects and a contributor to the wider scijava / fiji community! 🎆

[ctrueden]

Thanks @cmhulbert for working on this, and thanks @bogovicj for the introduction. 😸

Even when using these dependencies from a project which does not use the module system, it is still required to add the javafx jar files to the --module-path instead of the --classpath.

That is highly unfortunate.

I feel strongly that if it is at all possible, jgo needs to do the "right thing" automatically for all dependencies, both endpoints (i.e. explicit ones) and transitive/implicit ones. There must be a way to figure this out somehow by scanning for module-info.java across the involved JAR files in the environment.

I'd like to go over it with @gselzer, our resident JPMS expert, before we complexify jgo with additional CLI arguments.

If we conclude there is no way forward other than to pass the buck to the caller in this regard, then so be it, but in my view, the beauty of jgo is that you just give the endpoints and it runs. If this PR actually ends up being necessary in the end, I would feel compelled to change the tagline "painless Java component execution" to remove the word "painless."