The OpenRocket community would like to deliver OpenRocket as a snap package. OpenRocket is a java based application that has an existing user base which has been designing their own model and high powered rockets. In considering the user experience, we would like it to “just work” regardless of whether users are running the jar file, the installed debian package, or the snap.
The OpenRocket application access two hidden directories within the user’s home directory:
$HOME/.java/.userPrefs/OpenRocket - used by the Java Preferences API for storing user preferences on UI settings and application behavior
$HOME/.openrocket - used for storing application specific data (which includes a model rocket motor database, parts database, etc).
To facilitate a seamless transition for our user base, we request that the snapcraft store allows for the personal-files interface. The snapcraft.yaml file for the application narrowly scopes the request to only be what is required for the application:
The snap itself has not yet been published as it requires this approval before the store will accept the upload been published to the edge channel without these interfaces to facilitate any review. An account has been registered for OpenRocket to publish the resultant snaps under the official OpenRocket account.
Additionally, we would request that since the OpenRocket application uses appropriately named resources scoped to the application specifically that the interfaces be auto connected upon installation.
We are happy to make any necessary changes to facilitate the enablement and auto-connection of the personal-files interface for the OpenRocket snap package.
i’m not a reviewer, but i’m pretty sure they will ask you to somehow have “openrocket” in that interface name since it isnt just generically granting access to $HOME/.java/.userPrefs …
@wolsen - write access implies read so there is no need to list both - also can you rename the instance for ~/.openrocket to just dot-openrocket since this is clearer - so you can simplify the plugs to:
So it appears I’ve run into a problem. This will allow access to the necessary bits to store the data, but it turns out the java preferences code will attempt to access 2 additional files within the $HOME/.java/.userPrefs folder. These files are as follows:
Java uses these for lock files and coordination across multiple JVMs using the preferences tree. It will create the files if they don’t exist and simply use the files for locking [0][1].
The unfortunate thing is that the two paths include the username, which will naturally vary. I don’t believe the personal-files interface accepts wildcards.
No, personal-files does not support wildcards, so instead the best option would be to just change this to write access to all of $HOME/.java/.userPrefs - which isn’t as ideal but would work. In this case the name of the interface should also be changed to say dot-java-user-prefs.
+1 from me for this - can other @reviewers please vote?
If all the snap is trying to do is store openrocket java user prefs, why must it store them in $HOME/.java/.userPrefs/ rather than in $SNAP_USER_DATA or $SNAP_USER_COMMON? It makes me very uncomfortable to give write access to all of $HOME/.java/.userPrefs since this gives the snap the ability to access and change arbitrary user preferences that are unrelated to the snap. Eg, we don’t allow read/write access to $HOME/.config, why are we allowing it here?
However on reflection, since your original statement was about seamless transition, it would seem that perhaps a better option would have been just read access for both of these, so that you could copy them into $SNAP_USER_DATA/.java/.userPrefs/OpenRocket and $SNAP_USER_DATA/.openrocket respectively and then the snap would just use these snap-specific paths. So my preferred solution would be to change openrocket to include this migration and use the snap-specific paths instead - can you please comment?
@alexmurray and @jdstrand - I can work with the migration proposal suggested by Alex. Read-only access does indeed make more sense (though it does seem there should/could be a java preferences interface for java apps) and if the app can have read-only, I’ll work on the migration code.
Yes, write is still required for dot-openrocket. That’s where users will have an existing stash of various part and component databases; some from openrocket native and others from various other sources. Users will also be able to add parts which are stored in databases here. I’d really rather not have to give up the write access to this directory, since it is scoped specifically to openrocket (and even moreso than the $HOME/.java/.userPrefs).
I understand the need of keeping the write access to $HOME/.openrocket (also openrocket is the clear owner of the directory).
I have checked the openrocket declaration and it already has write access to $HOME/.openrocket using the interface reference dot-openrocket and read access to $HOME/.java/.userPrefs/OpenRocketusing the intereface reference dot-java-user-prefs-openrocket. Thus it’s my understanding that the request is completed and we can remove it from our queue.
