Provide packaging support

[puce77]

There are 3 more or less standard ways to package apart from Maven Assemblies:

• javapackager
• JavaFX Ant Tasks
• JavaFX Maven Plugin

Also see: http://javafx-maven-plugin.github.io/

[puce77]

Should the Drombler FX Maven Plugin directly support one of these tools? Or should it just make sure the user can configure the tool of choice and that it works nicely with Drombler FX?

[FibreFoX]

If you need any support, please contact me via e-mail.

[puce77]

@FibreFoX Thanks for your offer! At least the releasing of the two products have to be timed.

[puce77]

Running java -Duser.language=en -Duser.country=US -Djavafx.verbose=true -Dprism.verbose=true -Dbinary.css=false -Djava.util.logging.config.file=conf/logging.properties -jar bin/my-app.jar

in the app dir of the installed native application I get:

Calling main(String[]) method Exception in Application init method QuantumRenderer: shutdown java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:389) at com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:328) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:767) Caused by: java.lang.RuntimeException: Exception in Application init method at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:912) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$155(LauncherImpl.java:182) at java.lang.Thread.run(Thread.java:745) Caused by: org.drombler.acp.startup.main.MissingPropertyException: Undefined property: platform.userdir at org.drombler.acp.startup.main.DromblerACPConfiguration.determineUserDirPath(DromblerACPConfiguration.java:192) at org.drombler.acp.startup.main.DromblerACPConfiguration.<init>(DromblerACPConfiguration.java:102) at org.drombler.fx.startup.main.DromblerFXConfiguration.<init>(DromblerFXConfiguration.java:54) at org.drombler.fx.startup.main.DromblerFXApplication.init(DromblerFXApplication.java:53) at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:841) ... 2 more Exception running application org.drombler.fx.startup.main.DromblerFXApplication

[FibreFoX]

Caused by: org.drombler.acp.startup.main.MissingPropertyException: Undefined property: platform.userdir

Maybe there is some problem with "the current directory"?

[puce77]

Or maybe one of the resource files didn't get generated properly. (The default location of the userdir should be in a generated properties file of the main JAR.) I have to analyze it.

[puce77]

Cause: jfx:build-jar copies additionalAppResources including conf/config.properties dromblerfx:ensure-standalone-config ensures that conf/config.properties contains the userdir location jfx:build-native copies additionalAppResources including conf/config.properties again overwriting the changes made by dromblerfx:ensure-standalone-config

[puce77]

@FibreFoX since jfx:build-native relies on jfx:build-jar being run first and since jfx:build-jar already copies additionalAppResources, I don't see a need for jfx:build-native to copy additionalAppResources again. The code mentions https://github.com/javafx-maven-plugin/javafx-maven-plugin/issues/83 though. Or is "mvn clean jfx:native" (mentioned in that issue) really supposed to do something meaningful (without running jfx:build-jar)?

[puce77]

I removed that code now on the native branch. With these branches a Drombler FX application can be packaged (deb), installed and run: https://github.com/Drombler/javafx-maven-plugin/tree/native https://github.com/Drombler/drombler-fx/tree/137-packaging-support

[FibreFoX]

Nope, not the full picture.

• build-jar only generates the javafx-jar, and only copies <additionalAppResources> when <copyAdditionalAppResourcesToJar> is set to true (but it's false by default), it is responsible for generating the target/jfx/app-folder
• as build-native is iterating over all bundlers, it first generates the target/jfx/native/{appName}-folder which contains the native launcher and starts with copying the <additionalAppResources> "into it" (this is not true, see comment below)
• then build-native generates all installers with target/jfx/native/{appName} as it's base

<additionalAppResources> was ment for copying stuff like licenses, documentation and other stuff, which are not required while build-jar, but I see your point.

[FibreFoX]

Wait ... I have to step back ... I now do see your point more clear, I re-checked the target location, but it says ${project.build.directory}/jfx/app ... sorry. This will make my weekend a bit smaller I guess.

[FibreFoX]

Just a note: the build-jar-mojo only copies into ${project.build.directory}/jfx/app when requested (as it is required for jfx:run), but it is copied with build-native, thats maybe why you thought it comes from build-jar. But I still have to make bigger changes to clean everything up, maybe starting to work onto this: https://twitter.com/FibreFoX/status/820335033143664640

[puce77]

@FibreFoX interesting. I don't have yet a clear opinion yet, however, as I don't have the complete picture about native applications yet.