The cric snap contains it’s own custom runtime (command produced by cric) so it runs fine.
It’s up to the user of cric to provide the jlink command, JDK’s and jmods to work with, it can be from many providers and for many operating systems and in many different versions.
The problem is that in strict mode, cric is limited to home and removable-media,
that’s the reason for this request.
I first started out here and is open for other working suggestions than classic confinement.
Here’s a working snapshot of the snapcraft.yaml
name: cric
title: CRIC
base: core18
version: 1.0.1
summary: A Java jlink ui - a Custom Runtime Image Creator
description: |
**CRIC** is a gui for the Java jlink command.
It produces custom runtime images, kind of Java Runtime Environments.
The driver behind CRIC was the need to create cross-target custom runtime images for the non-modular application https://mapton.org.
https://github.com/trixon/cric
grade: stable
architectures: [ amd64 ]
confinement: strict
icon: snap/gui/cric.png
license: Apache-2.0
apps:
cric:
command: bin/launcher
extensions:
- gnome-3-34
plugs:
- home
- removable-media
parts:
cric:
plugin: dump
source: https://github.com/trixon/cric/releases/download/v$SNAPCRAFT_PROJECT_VERSION/cric-$SNAPCRAFT_PROJECT_VERSION-bin.zip
#source: /root/project/cric-$SNAPCRAFT_PROJECT_VERSION-bin.zip
source-type: zip
organize:
'*' : cric
launcher:
plugin: dump
source: snap/local
organize:
'launcher': 'bin/'
apt:
plugin: nil
override-build: |
apt install openjdk-11-jdk -y
jlink:
plugin: nil
after: [apt]
override-build: |
rm -rf $SNAPCRAFT_PRIME/jre
jlink --no-header-files \
--no-man-pages \
--strip-debug \
--compress=1 \
--add-modules java.base,java.datatransfer,java.desktop,java.logging,java.prefs,java.sql,java.xml,jdk.jfr,jdk.unsupported,jdk.unsupported.desktop \
--output $SNAPCRAFT_PRIME/jre
strip -p --strip-unneeded $SNAPCRAFT_PRIME/jre/lib/server/libjvm.so
No, I did not consider that, I might take a look at it.
My main concern with non-classic, except the “limitation of file access”, was the user friendliness of it all, but now that ogra helped out below I think I have a solution in reach.
@trixon based on your last comment it seems you will be able to keep your snap under strict confinement, is that correct? If that’s the case could you please edit this request title and detail here which specific interfaces you will require? Remember the use/auto-connection of some interfaces require approval Process for aliases, auto-connections and tracks.
As you have confirmed it is not needed, we are removing your request for classic confinement from our internal queue and there is nothing else you need to do from your side. You might want to mark the comment/answer that helped you with your needs as Solution and that should be all.
Regarding auto-connection for removable-media, if this is not a hard requirement for your snap to properly work, its preferred to have the snap user taking the decision to do it instead. This is because, as you might have read, all snaps with this interface connected have unrestricted access to all data from any plugged media.