Read only installers with java 12 'jpackage' tools (on Mac)

[Frank Lyaruu]

Hi, I'm replacing an old JNLP deployment pipeline. Adding a 'getdown' endpoint worked out pretty smoothly.

Now I'm trying to use the new 'jpackage' tool that will ship in JDK 12, that will package a 'native' kind of application. (btw, I am working on Mac for now, I'll need to get it to work on Windows as well but that's for later).

If I create an 'appication image' (on a mac, essentially an 'app shaped' folder) it works fine. Getdown uses that folder as appdir, downloads what it needs and runs fine.
But if I create an installer (a .pkg file that could also be submitted to the Mac appstore) it gets a read only folder, and it can't change it own code location.
So I need to use another location, but as I suspect it is/will be a common issue, I wonder if any here have thoughts about how to do this (what folder to use essentially). Did anyone experiment with this?

[Michael Bayne]

Is the app installed in /Applications or are you running the app from the read-only disk image that is often created for installing Mac apps? In the latter case, the expectation is usually that the user has to drag the application into their ~/Applications or /Applications folder.

I agree that it would be nice to allow the app to be run directly from a read-only disk image, which is technically possible if you ship a disk image with a fully downloaded and validated application.

The alternative of having the app download and install resources somewhere outside the .app dir has substantial drawbacks in my opinion. The user may just run your app (from the disk image) to try it out, and it then installs a bunch of stuff on their computer that they don't know about, and then they decide not to use it so they throw away the disk image, but all the downloaded resources remain wherever you installed them, unassociated with the app that installed them.

It would be nice if the OS gave us a better way to solve this problem (like per app data directories that are automatically deleted if the app is uninstalled), but without such a feature, I think it's worth trying to keep everything in the .app directory if possible.

Anyhow, all that said, you can use the "auto-create the app dir" mechanism to have the application stub installed by the .pkg file run Getdown with an appdir that is outside the .app directory (like ~/Library/Application Support/YourApp). For example, if you run the getdown testapp like so:

java -Dappbase=https://samskivert.com/code/testapp -jar target/testapp/getdown-new.jar "$HOME/Library/Application Support/TestApp"

That will auto-create a directory in Application Support and download, install and run the testapp in there. So something like this can probably be used to work around your issue, at the price of having your app leaving a bunch of cruft on the user's machine that will never get deleted.

--
You received this message because you are subscribed to the Google Groups "OOO Libs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ooo-libs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

-- m...@samskivert.com

[Frank Lyaruu]

On Friday, January 4, 2019 at 7:49:23 PM UTC+1, Michael Bayne wrote:

Is the app installed in /Applications or are you running the app from the read-only disk image that is often created for installing Mac apps? In the latter case, the expectation is usually that the user has to drag the application into their ~/Applications or /Applications folder.

Yes, that works, in that case the app has write permission.

 

I agree that it would be nice to allow the app to be run directly from a read-only disk image, which is technically possible if you ship a disk image with a fully downloaded and validated application.

But then the whole premise of getdown is gone, right? That would mean that any update would require an Apple appstore release, and for my case at least that's just not worth it.

It seems much  more a Mac problem than a GetDown or even an jpackage problem. If we need to write some data, as far as I can tell we don't have an 'official' place where we can put data where we can make sure it will be cleaned up when the application gets uninstalled.

The alternative of having the app download and install resources somewhere outside the .app dir has substantial drawbacks in my opinion. The user may just run your app (from the disk image) to try it out, and it then installs a bunch of stuff on their computer that they don't know about, and then they decide not to use it so they throw away the disk image, but all the downloaded resources remain wherever you installed them, unassociated with the app that installed them.

 

It would be nice if the OS gave us a better way to solve this problem (like per app data directories that are automatically deleted if the app is uninstalled), but without such a feature, I think it's worth trying to keep everything in the .app directory if possible.

Anyhow, all that said, you can use the "auto-create the app dir" mechanism to have the application stub installed by the .pkg file run Getdown with an appdir that is outside the .app directory (like ~/Library/Application Support/YourApp). For example, if you run the getdown testapp like so:

java -Dappbase=https://samskivert.com/code/testapp -jar target/testapp/getdown-new.jar "$HOME/Library/Application Support/TestApp"

That will auto-create a directory in Application Support and download, install and run the testapp in there. So something like this can probably be used to work around your issue, at the price of having your app leaving a bunch of cruft on the user's machine that will never get deleted.

I'll give that a spin, and report back how that worked out jpackage is still in dev so things may change there as wel.

Thanks for the input!

[Magikarp]

Thats a major drawback of linux aswell. In windows, I would just install the application files using getdown to %LOCALAPPDATA% and it works fine and all, but the major drawback is that I don't have such a folder for linux which is "write" enabled by default, like %LOCALAPPDATA%.

So how did it work out for you? What did you do to solve the issue?