Request for classic confinement: jenesis

store-requests classic-confinement
1
  • name: jenesis
  • description: A build tool for Java applications
  • snapcraft: jenesis/jreleaser.yml at main · raphw/jenesis · GitHub
  • upstream: https://github.com/raphw/jenesis/
  • upstream-relation: author
  • supported-category: build tool (IDE?)
  • reasoning: like other build tools, jenesis reads and writes arbitrary project trees anywhere on disk, writes ~/.jenesis and ~/.m2, and invokes the user’s JDK and other toolchain binaries, none of which strict confinement permits. Precedents: gradle, kotlin, uv, gh.

I understand that strict confinement is generally preferred over classic.

I’ve tried the existing interfaces to make the snap to work under strict confinement.

2

This request has been added to the queue for review by the @reviewers team.

3

Hello @raphw :slight_smile:

I believe that jenesis doesn’t meet this criteria because of the following reasons:

  • The project seems to be very fresh, according to the upstream repository
  • The projects seems to have little/none community around according to upstream repository (contributors, issues, PRs, etc.)
  • I could not find evidences that the project has a strong enough user base currently.

Thus, considering these factors, I think jenesis should not get classic confinement as of now.

However, I would suggest to try the following to get it working under strict confinement:

  • Bundle a JDK in the snap. Strict confinement can’t invoke the host JDK, so this is the one unavoidable trade-off.
  • home + network interfaces for project file access under $HOME and dependency downloads from Maven Central / the Jenesis overlay.
  • personal-files interface for ~/.jenesis and ~/.m

If you want to proceed with the these interfaces, please open a post in the store-requests category following the process for aliases, auto-connections and tracks.

4

Hello,

thanks for the feedback. it’s true that Jenesis is a rather new project, and part of popularizing it means to give people easy access to it.

The workarounds you suggest will not work.

Bundling a JDK defeats the purpose as a using project might require a specific version. I would need to ship multiple versions of Jenesis for each possible JDK distribution as this JDK is also used for invoking the tooling.

Jenesis has a compatibility mode with Maven, and this requires access to the same .M2 folder.

I understand that you do not want untrusted projects in snap but this skews the competition angle for incumbent open source in relation to for example Gradle that can be installed through snap with classic confiment. Platforms like homebrew solve this by offering integration through a local tap and only giving a global alias to established projects.

Again, I understand your perspective but I’d rather not ship a crippled version of my project through snap.

Best regards, Rafael