Native launcher on OS X => jars downloaded into ${user.home}, not into bundle

[carlosmonterocanabal]

I'm mac user and I'm testing you great FXLauncher. I see that FXLauncher downloads jar files into user.home variable and It would be great to set the target folder. In OS X it would be download into the .app folder in fact, because if you drop the icon app to trash, you don't uninstall all the app because all the jars it's outside. If you want to get the dir to save the jars on OS X the code is:

            final URL myURL = Client.class.getProtectionDomain().getCodeSource().getLocation();
    java.net.URI myURI = null;
    try {
        myURI = myURL.toURI();
                    final String dir = java.nio.file.Paths.get(myURI).toFile().toString();
    } catch (final URISyntaxException e){
    }

Thank you and keep the great job

[carlosmonterocanabal]

I have tested on Windows ant FXLauncher download jars into executable folder, so it works perfect. The problem is on Mac OS X that JVM current folder returns ${user.home}. So you have to use my code to get the current folder into .app bundle to work in the same mode as Windows.

[edvin]

Thanks for reporting this. I'm away this weekend, but I'll get to it on Monday :)

[edvin]

I just did a quick test on my Mac:

mkdir tmp && cd tmp
wget http://fxldemo.tornado.no/fxlauncher.jar
java -jar fxlauncher.jar

The dependencies controlsfx.jar and fxldemo-2.0.jar are downloaded to the tmp-folder as expected. Is that not what you see? What version of OS X and Java are you using?

[carlosmonterocanabal]

You have to test with the DMG (native installer)

[carlosmonterocanabal]

Java 8 update 20
OS X 10.10.1 Josemite

The problem is with the JVM when it started from the native installer.

[edvin]

Ah, I see. I wonder if it's possible to configure the working dir for the dmg installer via javapackager. That way we wouldn't have to handle this as a special case. Investigating now :)

[carlosmonterocanabal]

I think that it's not posible. You need get the current folder on execution (FXLauncher), not in compile/package phase. I'm working in another app that runs a Jetty server embebed and I had to get the war into de DMG, and the solution I found (I was around 4-5 hours testing a lot ways) is the code I wrote before.

[edvin]

I downloaded (http://fxldemo.tornado.no/FxlDemo-2.0.dmg) and copied it to /Applications. Then I checked the content of /Applications/FxlDemo.app/Contents/Java:

FxlDemo.cfg
fxlauncher.jar

Then I started the app, waited for it to update and checked the folder again:

FxlDemo.cfg
controlsfx.jar
fxlauncher.jar
fxldemo-2.0.jar 
no.tornado.FxlDemo.xml

Can you try with the same installer to see if your result is different? It might be a Java Version issue as well, you're version is quite dated. I'm running 1.8.0_66. If your result is different, it would be interesting to see what happened if you updated to the latest release.

Just want to make sure I know what's causing this before I make any adjustments :)

[edvin]

I didn't mean we'd hard code some path via javapackager, but I though maybe there would be an option to specify that the current working directory should be where the app is installed. That's how it works for me by default.

[edvin]

Did you include the identifier argument to javapackager by the way?

-Bidentifier=${project.groupId}.${project.artifactId}

Or something similar?

[carlosmonterocanabal]

I have tested FXDemo.dmg and it works as espected. So I think the Java version is the problem. I will test with latest version.

My conf to javapackager is:

                  <arguments>
                            <argument>-deploy</argument>
                            <argument>-native</argument>
                            <argument>-outdir</argument>
                            <argument>${app.installerdir}</argument>
                            <argument>-outfile</argument>
                            <argument>${app.filename}</argument>
                            <argument>-srcdir</argument>
                            <argument>${app.dir}</argument>
                            <argument>-srcfiles</argument>
                            <argument>fxlauncher.jar</argument>
                            <argument>-appclass</argument>
                            <argument>fxlauncher.Launcher</argument>
                            <argument>-name</argument>
                            <argument>${app.filename}</argument>
                            <argument>-title</argument>
                            <argument>${app.filename}</argument>
                            <argument>-vendor</argument>
                            <argument>${app.vendor}</argument>
                            <argument>-Bicon=${project.build.directory}/..${icon.bundle}</argument>
                            <argument>-BappVersion=${app.version}</argument>
                            <argument>-Bidentifier=${project.groupId}.${project.artifactId}</argument>
                        </arguments>

I will test with another Java version and tell you the results

[edvin]

Thank you. I'm really curious to find out what's causing this :)

[edvin]

I'm just discussing with another user on an email thread, and we're looking into adding a --cache-dir parameter to fxlauncher. This could support a "magical" parameter that would mean different folders depending on the OS. For example:

--cache-dir=$USERLIB/MyApp

Would cause the downloaded artifacts to be installed in the following places, depending on OS:

OS	Location
Windows	~/AppData/MyApp
Mac	~/Library/Application Support/MyApp
Linux	~/.MyApp

If no --cache-dir parameter is given, the current folder is used. Maybe $USERLIB isn't a great variable name, but something like that. Would that be helpful?

[carlosmonterocanabal]

Solved! It was java version. With the same configuration, using jdk1.8.0_91 it works fine.
I think the actual behavior is the correct => Download into app folder.
The only advantage into set a external folder is if you distributed a suite and you want to share libs (same versions) between apps, the first app started download all jars, and the other apps only download his custom libs.

I think we can close the issue and alert people than 8u20 on Mac OS X doen´t work as espected.

[edvin]

OK! I might add the parameter anyway, it won't affect existing configurations, but might be helpful to some people, and as you point out, it could actually be used for sharing libs between apps :) Thanks for reporting this!

[carlosmonterocanabal]

Thank you for your lib and keep the good work! It's very helpful 👍

[edvin]

Thanks :) Be sure you check out TornadoFX if you want to try a super charged way of building JavaFX apps :))