Should I have to create hooks folder inside my applications root directory and put that script inside it?
You should just be able to create the hooks dir in the snap folder in your project’s root directory, i.e. if your project is located in your home folder under project1, then you would have snapcraft.yaml either at:
/home/user/project1/snapcraft.yaml
or
/home/user/project1/snap/snapcraft.yaml
and run snapcraft from
/home/user/project1
In both of these cases, put the install hook here (with the filename verbatim install):
/home/user/project1/snap/hooks/install
Does that make sense?
Thanks for your response. Now I can understand it 
I’ve created a directory inside snap called hooks and placed install script there and made it executable. After the package installation it does not copy config files to $SNAP_USER_DATA automatically.
But If I go the snap environment using this command snap run --shell myapp and run the script manually it copies my config files to $SNAP_USER_DATA.
I don’t know what I’m missing. Please correct me if anything wrong.
the install hook only runs during installation of the snap.
this means it runs as root and not as some user.
as such, the $SNAP_USER_DATA variable only points to /root/snap/<packagename>/current/ at that time.
if you want to copy to $SNAP_USER_DATA during first start of the app when a user runs it (so the variable actually points to that users dir), you rather want to run your app from a wrapper script with a line like:
@ogra The solution you proposed works fine. But should I have to hardcode the config file path ($SNAP_USER_DATA/config.properties) inside my code or is there any other method to mention the path of configuration file?
how would I know 
i havent seen your code …
I’d make the code read the environment variable, If it is set to something non-zero it is clear you want to use the config from there … if it is unset, use the default non-snap config location
I’ve also having another issue. My Java application is built with the help of third party SDK. So I have to use their license in order to run the application.
The license should be running as a separate instance in the installed machine.
After the packaging of application along with its dependencies and licenses using snap, Our Java application is not detecting the running license instance.
The License file will be run through the shell script which is provided by the SDK, will be running locally on port 5000.
Should we have follow any other steps while packaging the application particularly for this type of licensing?
I’ve attached my snapcraft.yaml file below
name: facecheck # you probably want to 'snapcraft register <name>'
base: core18 # the base snap is the execution environment for this snap
version: '1.0' # just for humans, typically '1.2+git' or '1.3.2'
summary: Face recognition # 79 char long summary
description: |
This application is used to recognise and detect the persons face
with the enrolled data from database.
grade: devel # must be 'stable' to release into candidate/stable channels
confinement: devmode # use 'strict' once you have the right plugs and slots
apps:
facecheck:
# command: usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -jar $SNAP/Bin/Java/simple-surveillance-application.jar
command: wrapper
# environment:
# JAVA_HOME: $SNAP/usr/lib/jvm/java-1.8.0-openjdk-amd64
# PATH: $JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH
# LD_LIBRARY_PATH: $SNAP/Lib/Linux_x86_64
plugs: [desktop, home, camera, x11, desktop-legacy, opengl, alsa, pulseaudio, network, network-bind]
autostart: Facecheck-surveillance.desktop
parts:
facecheck:
# See 'snapcraft plugins'
source: .
plugin: dump
build-packages:
- nvidia-384-dev
- libgtk-3-dev
- gstreamer1.0-vaapi
- vainfo
- openjdk-8-jre
- openjdk-8-demo
- libgdk-pixbuf2.0-dev
- alsa-utils
- libasound2-data
- libasound2-plugins
- libasound2
- libopus-dev
- libortp-dev
- gcc
- g++
- make
- libgudev-1.0-0
- libgudev-1.0-dev
- libgstreamer1.0-0
- gstreamer1.0-plugins-base
- gstreamer1.0-plugins-good
- gstreamer1.0-plugins-bad
- gstreamer1.0-plugins-ugly
- gstreamer1.0-libav
- gstreamer1.0-doc
- gstreamer1.0-tools
- gstreamer1.0-x
- gstreamer1.0-alsa
- gstreamer1.0-gl
- gstreamer1.0-gtk3
- gstreamer1.0-qt5
- gstreamer1.0-pulseaudio
- libfontconfig1-dev
- libfreetype6-dev
- libpng-dev
- libcairo2-dev
- libjpeg-dev
- libgif-dev
- libgstreamer-plugins-base1.0-dev
- python-gst-1.0
- python3-gst-1.0
- postgresql
- postgresql-contrib
- odbc-postgresql
- unixodbc
- unixodbc-dev
- build-essential
- manpages-dev
stage-packages:
- libgpm2
- libslang2
- libnvidia-compute-390
- openjdk-8-jre
- openjdk-8-demo
- nvidia-384-dev
- libgtk-3-dev
- gstreamer1.0-vaapi
- vainfo
- libgdk-pixbuf2.0-dev
- alsa-utils
- libasound2-data
- libasound2
- libasound2-plugins
- gcc
- g++
- make
- libgudev-1.0-0
- libgudev-1.0-dev
- libgstreamer1.0-0
- gstreamer1.0-plugins-base
- gstreamer1.0-plugins-good
- gstreamer1.0-plugins-bad
- gstreamer1.0-plugins-ugly
- gstreamer1.0-libav
- gstreamer1.0-doc
- gstreamer1.0-tools
- gstreamer1.0-x
- gstreamer1.0-alsa
- gstreamer1.0-gl
- gstreamer1.0-gtk3
- gstreamer1.0-qt5
- gstreamer1.0-pulseaudio
- libfontconfig1-dev
- libfreetype6-dev
- libpng-dev
- libcairo2-dev
- libjpeg-dev
- libgif-dev
- libgstreamer-plugins-base1.0-dev
- python-gst-1.0
- python3-gst-1.0
- postgresql
- postgresql-contrib
- odbc-postgresql
- unixodbc
- unixodbc-dev
- build-essential
- manpages-dev
if network and network-bind are connected after installation your app should definitely be able to connect to localhost:5000 …
ok, I’ll check other settings in my application.
I’m also getting some error from alsa, even though I’ve mentioned it in a plugs, and I can see the file /usr/share/alsa/alsa.conf in my snap application. But it says it can’t access
ALSA lib conf.c:3916:(snd_config_update_r) Cannot access file /usr/share/alsa/alsa.conf
ALSA lib control.c:1373:(snd_ctl_open_noupdate) Invalid CTL hw:0
I’m also getting some warning in my application
Gtk-Message: 18:22:59.254: Failed to load module "overlay-scrollbar"
Gtk-Message: 18:22:59.254: Failed to load module "unity-gtk-module"
Gtk-Message: 18:22:59.257: Failed to load module "canberra-gtk-module"
add a part for alsa-lib to your snapcraft.yaml, like i do in line 67-88 in:
then make your faceckeck: part have a line like:
after: alsa-lib
like in line 90:
and set the alsa config path in your app environment like:
the gtk module warnings can be safely ignored …
@ogra Thanks for your help, I’m not getting cannot access file /usr/share/alsa/alsa.conf error now, but I’m still getting below error.
ALSA lib control.c:1373:(snd_ctl_open_noupdate) Invalid CTL hw:0
Also I’m getting below exception
java.io.IOException: Cannot run program "/usr/bin/xprop": error=2, No such file or directory
but I can see xprop is present in the /usr/bin/ location
did you also add the audio-playback interface (and perhaps pulseaudio) ?
but your snap can not …
put x11-utils into your stage packages and map $SNAP/usr/bin/xprop to /usr/bin/xprop using a Layout
This solution works.
yes, I’m using pulseaudio plug in my yaml file
try also adding audio-playback, are there any denials in your journal while the alsa error occurs ?
no, just the error message prints, and my application launches as usual. only my licensing instance it not recognised by my application
well, if you dont actually need sound output, i’d just ignore it …
regarding the licensing server i have no idea, does the app perhaps have any options to define where the server runs (i.e. you could try to point it to the external IP instead of localhost) ?
Thanks for your help. I can’t change the ip address. It will be running locally in the installed system
Please give me a detailed guide. I added in the snapcraft.yaml
base: core18
apps:
languagetool:
command: usr/bin/run.sh
plugs: [network, network-bind, x11, home, unity7, desktop, desktop-legacy, gsettings, wayland, audio-playback]
...
stage-packages:
...
- openjdk-8-jre
- x11-utils
The program starts and works, but I get an error.
java.io.IOException: Cannot run program “/usr/bin/xprop”: error=2, No such file or directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
this looks like your java binary hardcodes /usr/bin instead of respecting the systems PATH setting … if you can not change the source of the java app to fix this, you can use a layout to map xprop from inside the snap to be seen at /usr/bin/xprop by the application like:
layout:
/usr/bin/xprop:
symlink: $SNAP/usr/bin/xprop