hello guys, is it possible to create a MSIX package with the jetpack compose desktop gradle plugin?...

# compose-desktop

[Radoslaw Juszczyk]

hello guys,

is it possible to create a MSIX package with the jetpack compose desktop gradle plugin?

I used to create a MSI package, and then use the MSIX Package Tool to create a MSIX package from it but recently I started to face an issue when the JVM is not included (or cannot be found) after installing from MSIX and am no longer able to create functional MSIX packages.

[Alexander Maryanovsky]

@alexey.tsvetkov Can you assist?

[spierce7]

No. We had to move to https://conveyor.hydraulic.dev/8.1/ to get MSIX

[spierce7]

I recommend it

[Adam Brown]

snap/flatpack/msix would be awesome out of the box. Hydraulic is cool, but not open or free (for FOSS yes)

[Adam Brown]

is there a mac equivalent? is it dmg? I dont use macs 😛

[Radoslaw Juszczyk]

Conveyor looks great but 45usd per month is more or less what my app generates :/

[Adam Brown]

exactly

[Adam Brown]

and these aren't like... proprietary formats, one of us FOSSers gotta make a gradle plugin to produce these 😛

[mikehearn]

@Adam Brown It's free for FOSS apps

[mikehearn]

oh sorry

[mikehearn]

I misread "yes" as "yet"

[mikehearn]

BTW, I run Hydraulic. I'll say that we're a little company and willing to be creative or take feedback on pricing. Experimenting with pricing is on our todo list actually. The main reason it's priced that way right now is support costs + smallish market. People get stuck, they've paid, so they need help. Or they hit bugs in operating systems, or in Java, or in libraries they use (or sometimes even in Conveyor!), and then need help or workarounds to be developed. That takes time and costs money.

For some reason in the past couple of weeks the case of non-FOSS but also non-commercial or very small scale projects have come up a lot whereas it never came up before. That's definitely a gap in our pricing model. The problem is, the moment there is usage there is a support cost. If we don't fix people's problems then they will get annoyed or tell other people that it's buggy. FOSS projects tend to be more forgiving in this respect because they know they didn't pay.

Trying to make an open source Conveyor won't really fix this issue. You're just signing yourself up for maintenance demands without any reward, and that's been tried lots of times. It leads to either abandonment or just giving up and re-scoping as "we just do a bit of wrapping around the native tools" which is fine but isn't actually the problem people have, and there are lots of such tools already (like jpackage).

Summary: I'm open to ideas here. Rev shares, support-free options, etc. I'm sure there's something that can work for small projects just getting started, but which also doesn't flood us with money-losing support loads.

[mikehearn]

One thing to watch out for if you do try and make your own support for this - MSIX is great tech in some ways, but a big driver of support costs is that Windows has a lot of bugs, especially on older machines where the users aren't updating. A significant chunk of the work that has gone into Conveyor is remotely diagnosing obscure bugs in Windows we can't reproduce and then working around them. Some bugs are even in the Windows kernel. The result is that users get the benefits whilst being abstracted from the pain but that is definitely "work" and not "fun hacking" which is why we need to get paid for it.

[Adam Brown]

oh wow I wouldn't have expected windows to have so many problems with their own package format 😂 I totally understand wanting & needing to monetize something like this. My use case right now is FOSS so I have been planning on using Hydraulic once I get to that stage, but something about currently using pretty much 100% FOSS libs & tools made me wish there was also an open solution to this problem.

[mikehearn]

@Adam Brown You would think so, but modern Windows is a troubled project indeed.