@pmi - ping, this request cannot proceed without the requested information?
Sorry it took me so long to get back to you !
@alexmurray
Configuring gradle to use /home/user/snap/enonic/.gradle is a solution we actually considered too ! But we found it to have 2 drawbacks:
- Specifying
/snap/enonic/.gradlefolder will requiregradleto download both gradle distros (since we use gradle wrapper) and dependencies into that folder, even though they may be present in the main gradle folder at<user>/.gradle. Therefore we would like to reuse main folder as much as possible. -
/snap/enonic/.gradlefolder will not be known for user and may cause some confusion for power users debugging dependency conflicts of their deps.
So regarding your concern about conflicting gradle versions, I would say that there is a bigger chance of that in case of 2 gradle repositories, than just one 
And you’re absolutely correct that enonic is not the owner of both .gradle and .m2 folder , but it never tries to access them directly either – we need the access rights for gradle that is invoked by enonic, so there should not be any inapropriate use of that folder.
Hope this clears things a bit !
Thanks for the response - since enonic must ship it’s own gradle version I am still concerned that this may cause issues if there is a different version of gradle on the host which is already using the ~/.gradle folder - also if enonic uses the snap specific ~/snap/enonic//.gradle` I would have thought this would help avoid the chance of dependency conflicts and so there would be less need to debug anything in this case.
As such, I am wary to vote for auto-connect for this access - but I think it might make sense to grant this to be allowed for manual connection. Can you please clarify whether there is likely to be issues due to a different versions of gradle being used to access the same ~/.gradle?
Well, enonic is shipped with gradle wrapper instead of gradle. Wrapper is responsible for downloading and using the specified gradle version. So you are able to bump gradle version on end user machine by just bumping it in gradle wrapper config file in your project.
I have found a comprehensive description about the purpose and structure of .gradle folder here https://docs.gradle.org/current/userguide/directory_layout.html
Here’s the list of what’s inside it:
- Global cache directory (for everything that’s not project-specific)
- Version-specific caches (e.g. to support incremental builds)
- Shared caches (e.g. for artifacts of dependencies)
- Registry and logs of the Gradle Daemon
- Global initialization scripts
- JDKs downloaded by the toolchain support
- Distributions downloaded by the Gradle Wrapper
- Global Gradle configuration properties
In a nutshell, it is intended to be shared among different gradle versions so there is absolutely no chance anything going wrong if different gradle versions access it
I’d also like to remind that we still need a read-only access to /<user>/.m2 folder for gradle uses maven dependency repository.
Thanks for providing the extra information, +1 from me then for personal-files access as follows for enonic:
dot-grade:
interface: personal-files
write:
- $HOME/.gradle
dot-m2:
interface: personal-files
read:
- $HOME/.m2
Can other @reviewers please vote?
Same from me, +1 from me then for personal-files access for enonic.
+2 for, 0 against, 0 abstained, granting personal-files access as follows for enonic:
dot-grade:
interface: personal-files
write:
- $HOME/.gradle
dot-m2:
interface: personal-files
read:
- $HOME/.m2
@pmi, would you please update your snapcraft.yaml, test, and publish a new version. After that, I’ll aprove access to personal-files
@pmi I have checked and I see you have not updated your snap declaration yet. Could you please do so? This way we can proceed with the approval. Thanks!
@pmi can you please make the requested change to the enonic snap to declare these two new personal-files instances and upload a new revision so we can proceed with granting this request?
Terribly sorry for my absence, guys !
Will do it by the end of the week !
One thing: there is a typo in a dot-grade interface – should be dot-gradle probably.
Sorry for delays once more and happy new year 
Yes, I made changes and uploaded it finally !
It took a little longer than expected, because there were no point in releasing new version without any changes to the app itself 
Since voting/tailing was already performed, granting auto-connection for plugging personal-files with write access to $HOME/.gradle and read access to $HOME/.m2 using the interface references dot-gradle and dot-m2 respectively. This is now live.
1 Like
Hello @reviewers,
.m2 and .gradle permissions did the trick and gradle now works fine !
But it seems there is an issue when running enonic XP server from cli. Moving executable inside snap folder allowed it to start, but there are exceptions in server logs apparently thrown by elasticsearch that we use:
Caused by: org.apache.felix.log.LogException: java.io.IOException: failed to obtain lock on /home/pavel/snap/enonic/common/dot-enonic/sandboxes/Sandbox1/home/repo/index/data/mycluster/nodes/49
at org.elasticsearch.env.NodeEnvironment.<init>(NodeEnvironment.java:186)
... 60 common frames omitted
Caused by: java.io.IOException: Mount point not found
at java.base/sun.nio.fs.LinuxFileStore.findMountEntry(LinuxFileStore.java:105)
at java.base/sun.nio.fs.UnixFileStore.<init>(UnixFileStore.java:69)
at java.base/sun.nio.fs.LinuxFileStore.<init>(LinuxFileStore.java:49)
at java.base/sun.nio.fs.LinuxFileSystemProvider.getFileStore(LinuxFileSystemProvider.java:51)
at java.base/sun.nio.fs.LinuxFileSystemProvider.getFileStore(LinuxFileSystemProvider.java:39)
at java.base/sun.nio.fs.UnixFileSystemProvider.getFileStore(UnixFileSystemProvider.java:373)
at java.base/java.nio.file.Files.getFileStore(Files.java:1488)
at org.elasticsearch.env.ESFileStore.getMatchingFileStore(ESFileStore.java:89)
at org.elasticsearch.env.Environment.getFileStore(Environment.java:318)
at org.elasticsearch.env.NodeEnvironment$NodePath.<init>(NodeEnvironment.java:93)
at org.elasticsearch.env.NodeEnvironment.<init>(NodeEnvironment.java:175)
... 60 common frames omitted
and here is the corresponding journal entry:
apr 01 17:30:45 pavel audit[2637]: AVC apparmor="DENIED" operation="open" profile="snap.enonic.enonic" name="/proc/2637/mounts" pid=2637 comm="FelixStartLevel" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
It looks that elasticsearch tried to get mounts to get lock on /home/pavel/snap/enonic/common/dot-enonic/sandboxes/Sandbox1/home/repo/index/data/mycluster/nodes/49 ?
Are there any permissions needed for that operation as well ?
Thanks
Worked like a charm !
Thanks @alexmurray !
Can we have it auto connected for a snap ?
Enonic cli is a tool built for Enonic XP server, so it is essential to be able to run XP server for every user.
Would it be possible to re-list the new requirements and tag the relevant reply so it’s easier to review please? Or is this only for mount-observe?