I'm creating our new Launcher App for OpenRefine (using JavaFX on all 3 OS's) to allow users to Start, Stop, Show Logs, etc.
Here's the very crude beginnings and I intend to make it look and feel like a beautiful app launcher with our logo, many style and layout improvements, but for now its this minimal viable product MVP (absolutely anything and everything can be changed, which is great!):
Should we perhaps just launch OpenRefine's jar? is that OK? I'm thinking of something like:
private void startBackgroundOpenRefine() {
// Path to the OpenRefine application we want to start
String javaAppPath = "path/to/openrefine.jar";
ProcessBuilder processBuilder = new ProcessBuilder("java", "-jar", javaAppPath);
try {
Process process = processBuilder.start();
// Optionally, we can handle the process's input/output streams here
} catch (IOException e) {
e.printStackTrace();
}
}
As I begin wiring things up and getting the classpath and jre things aligned for the JavaFX launcher...would we be for or against packaging an uber jar to make things simpler? Any downsides on that? I'm wondering how that might affect @apo work also on Linux packaging or Mac?
But for now, I'm stuck on the basic command line itself for launching:
java -cp F:/openrefine-3.8.2/server/target/lib/*.jar -jar F:/openrefine-3.8.2/server/target/lib/openrefine-3.8.2-server.jar com.google.refine.Refine
no main manifest attribute, in F:/openrefine-3.8.2/server/target/lib/openrefine-3.8.2-server.jar
If I try to run it as a non-executable jar, then I get this:
java -cp F:/openrefine-3.8.2/server/target/lib/openrefine-3.8.2-server.jar com.google.refine.Refine
Error: Unable to initialize main class com.google.refine.Refine
Caused by: java.lang.NoClassDefFoundError: org/eclipse/jetty/server/Server
Well, son of a gun !!! Retrying with only passing the classpath as the main /lib/* folder:
java -cp F:/Downloads/openrefine-3.8.2/server/target/lib/* com.google.refine.Refine
01:14:46.597 [ refine_server] Starting Server bound to '127.0.0.1:3333' (0ms)
01:14:46.635 [ refine_server] Initializing context: '/' from 'E:\IntelliJ IDEA Projects\OpenRefine\main\webapp' (37ms)
01:14:49.279 [ refine] Starting OpenRefine 3.9-SNAPSHOT [TRUNK] ... (2643ms)
01:14:49.279 [ refine] Initializing FileProjectManager with data dir: C:\Users\thadg\AppData\Roaming\OpenRefine (0ms)
Great that you got this unstuck!
If you can make it work without changing the way our class files are packed up into jar files, that's great. I think it's cleaner to keep the dependencies in separate jar files.
Not only unstuck... it starts and launches browser.
And I got the logging finally figured out and showing in the Details panel (which we'll figure out how to collapse with the LOG button later on.
Now, I am really stuck on the STOP button error. When clicked, it seems that process object is not carried over for the onStopButtonClick() method and so it sees process as null ?
And since that happens... of course the process is not destroy, and the background Java process for the running OpenRefine just keeps on running and I have to EndTask on it in Windows Task Manager. (On Linux you'd have to kill the pid, same thing).
Caused by: java.lang.RuntimeException: java.lang.NullPointerException: Cannot invoke "java.lang.Process.isAlive()" because "this.process" is null
at org.openrefine.launcher@1.0-SNAPSHOT/org.openrefine.launcher.Controller.onStopButtonClick(Controller.java:101)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
... 57 more
Fixed! It starts and stops on Windows (at least).
Now need to figure out the best way to provide the Launcher with the OpenRefine path. Make it relative? config? What do we expect the packaging to look like?
@antonin_d (when you're back from vacations) I need help on packaging / module stuff, its making my head spin.
But in the meantime, got a few more features working also like confirm X close window that shows a dialog with the CANCEL as a default button.
I think it makes sense to also say "save projects" because when I call the process to terminate (which is supposed to be the same as on Windows with CTRL-C in the terminal), I think it is safely exiting and ProjectManager is doing its thing?
Agree @tfmorris ? can you confirm or ?
Hi! In Debian we don't really benefit from uber jars because the assumption is that users install required dependencies as separate packages and then the start script of any application will just define the classpath, additional parameters, etc. and run the application. Distributing an uber jar is a good generic solution for people who don't want to use system libraries but for an official Debian package, it would mean bundling existing libaries again.
I think it makes sense to also say "save projects" because when I call the process to terminate (which is supposed to be the same as on Windows with CTRL-C in the terminal), I think it is safely exiting and ProjectManager is doing its thing?
Agree @tfmorris ? can you confirm or ?
I don't know how you're terminating the process, so it's hard to say off the top of my head, but I guess I'd flip it around and say that you need to make it so the message is correct and projects get saved. I suspect they are, but it'd be good to test it. Basically as long as the exit handlers have a chance to run, you should be OK. An exception would be if you were doing the equivalent of Unix's kill -9 which unconditionally terminates the process.
Well, son of a gun !!! 
