Change timing of log submission

[dmusican]

We need a system for making a distributable build integrating into IntelliJ, so we can create a zip/jar/whatever that people can download. It should include a JRE within it so we're not dependent on which version of Java they have installed. Look at BlueJ or other Java software (Eclipse?) for best practices on how to do this, or possibly documentation at Oracle.

[grahamearley]

This is the Maven plugin that does it: https://github.com/javafx-maven-plugin/javafx-maven-plugin

[grahamearley]

Builds native app with mvn jfx:native in the Terminal tab of IntelliJ

[dmusican]

Check out Windows and Linux issues

[dmusican]

Make it part of the build in IntelliJ

[grahamearley]

How to add native/JAR app packaging to your build in IntelliJ:

1. Click the dropdown menu for "Build Configurations" right next to the green Play button in the top right corner of IntelliJ
2. Select "Edit Configurations"
3. In the top left of the new window, click the plus button to add a new configuration.
4. Select the "Application" option.
5. Name it to your liking (e.g. "Build native app")
6. Choose the main class to be main.java.elegit.Main
7. In the bottom of the window, click the plus button to add a new task to the "Before Launch" section.
8. Choose "Run Maven Goal"
9. In the "Command Line" field, enter jfx:native (for native builds) or jfx:jar (for JAR builds).
10. Save the configuration and then select it in the dropdown and press play!

[dmusican]

This needs to be nailed down specifically for Linux, making sure it can install. But getting it right on all three major OSes should be done.

[shangdrk]

I can now build it on Linux without changing anything in pom.xml. I think our pom.xml is correct, but somehow when I first cloned this repo on Linux, IntelliJ told me to import changes from maven, and after I did there was a weird line added to pom.xml which caused an error. But then I simply deleted that line and the build was successful.

However, there is another issue with the .deb file. I tried to install Elegit by running the .deb file, but after I installed it the Elegit-1.0-SNAPSHOT executable file wouldn't run, and the terminal is giving me the following error:

Elegit-1.0-SNAPSHOT No main class specified Elegit-1.0-SNAPSHOT Failed to launch JVM

But if I run Elegit-1.0-SNAPSHOT in the native folder in our repo (target/jfx/native), that version works fine. I don't know what's going on with the .deb file.

[dmusican]

That's not the same error I had received; it was something involving the organization not being specified, or something like that. It sounds like the .deb file may not be including the JVM. Perhaps that's something you can look into?

[shangdrk]

@dmusican I found something (in Debian Policy Menu) related to the "maintainer-address-malformed" warning: https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Maintainer

If the user just chooses to ignore and continue, the package will still be successfully installed. In terms of the bug when launching the program, I found a fix in an issue discussion of the javaFX maven plugin tool: https://github.com/javafx-maven-plugin/javafx-maven-plugin/issues/124

It turns out that the bug traces back to a bug in JavaSDK, and a workaround is to give our package a simpler name (so I changed its name from Elegit-1.0-SNAPSHOT to Elegit). As long as there's no dot in the name, there shouldn't be an issue.

However, after the program successfully ran, the terminal gives me another java error:

ERROR StatusLogger File not found in file system or classpath: src/main/resources/elegit/config/log4j2.xml ERROR StatusLogger No log4j2 configuration file found. Using default configuration: logging only errors to the console. java.io.FileNotFoundException: src/main/resources/elegit/config/log4j2.xml (No such file or directory) at java.io.FileInputStream.open0(Native Method) at java.io.FileInputStream.open(FileInputStream.java:195) at java.io.FileInputStream.<init>(FileInputStream.java:138) at main.java.elegit.Main.start(Main.java:34) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$162(LauncherImpl.java:863) at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$175(PlatformImpl.java:326) at com.sun.javafx.application.PlatformImpl.lambda$null$173(PlatformImpl.java:295) at java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.application.PlatformImpl.lambda$runLater$174(PlatformImpl.java:294) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) at com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method) at com.sun.glass.ui.gtk.GtkApplication.lambda$null$49(GtkApplication.java:139) at java.lang.Thread.run(Thread.java:745)

[dmusican]

We're now going to prioritize Mac install. Check with mtie, let him know what we want to do, make sure he's ok with it

[FibreFoX]

(Disclaimer: I'm the maintainer of the javafx-maven-plugin and the one who found that nasty bug) Hi there,

just saw the reference to some older bug and wanted to drop some comment : When using the javafx-maven-plugin, please set the <appName> as something without a dot, e.g. "Elegit". otherwise executing the native build will break.

As part of the investigations of another bug, I hit the situation about native bundlers still not being able to create nice launchers (and all due to the native linux launcher which is used for mac too as it seems to me). When you are still creating some native launcher using "linux.app" as bundler-id, it will get fixed .... but it seems that my fix wasn't longlasting enough ;)

Oh, and please update to the latest plugin-version ;)

[dmusican]

FibreFoX: thanks for finding our little project and piping in! We'll give that a shot, and also upgrade.

[dmusican]

@dmusican helping out

[FibreFoX]

@dmusican if you need support, don't hesitate to ping or email me :smile_cat: always here to help users with the plugin ;)

[dmusican]

FileNotFound issue masterfully fixed by FibreFoX in pull request #169. I've merged this into master. Nonetheless, an issue remains in writing the log file; you can't write a log file inside a jar. A fix needs to be made so that the log file goes somewhere in the actual file system, not inside the location determined by the jar. @erictwalker18 , can you take this again from here?

[erictwalker18]

Yep! Looking for a better location for log files. In the mean time, fixed a small bug with the xml for legend and branch manager. Fix was awesome :)

[FibreFoX]

As the application will get installed or run at some installed location, getting the working-directory might be the right choise: http://stackoverflow.com/a/15954821/1961102

Path currentRelativePath = Paths.get("");
String s = currentRelativePath.toAbsolutePath().toString();
System.out.println("Current relative path is: " + s);

Having some absolute path inside the code might not always resolve right on all operating systems :smile_cat:

[erictwalker18]

Thanks for the suggestion! I implemented it using temp directories, but this will work better once we start rolling out the tool for use besides one-day user studies.

[erictwalker18]

Implemented via d1f4502ffad33248cec79c2570626edd17f62bda. Uses relative path and submits at the time of fetching.