Native launcher on OS X => jars downloaded into ${user.home}, not into bundle about fxlauncher HOT 17 CLOSED

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.

from fxlauncher.

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

from fxlauncher.

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?

from fxlauncher.

You have to test with the DMG (native installer)

from fxlauncher.

Java 8 update 20
OS X 10.10.1 Josemite

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

from fxlauncher.

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 :)

from fxlauncher.

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.

from fxlauncher.

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 :)

from fxlauncher.

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.

from fxlauncher.

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

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

Or something similar?

from fxlauncher.

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

from fxlauncher.

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

from fxlauncher.

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:

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?

from fxlauncher.

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.

from fxlauncher.

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!

from fxlauncher.

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

from fxlauncher.

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

from fxlauncher.