A modern programming language that makes developers happier.

kotlinlang

Screenshot 2022-10-26 at 14.20.58.png

Hi all!

I am writing a small toolbox-style app, and I am using kotlinx serialization to deserialize a YAML file via the Kaml library.

All works perfectly when launching the app directly, but by generating a package (e.g. dmg or msi) and installing the app, it seems the de-serializer gets thrown out.
That, and also the `packageDmg` also uses proguard, when it isn’t supposed to as per documentation, and also disabling obfuscation via the `buildTypes.release.proguard.obfuscate = false` still runs proguard. Very strange.
Any ideas?
This is the error I get:

I have tried setting up a proguard file with kotlinx serialization stuff in it, but it still gives me that error

okay, I’ve just managed to make it work by setting:

```buildTypes.release.proguard.isEnabled.set(false)```
but still I would like to solve the problem at the base (via a proguard configuration)

&gt; That, and also the `packageDmg` also uses proguard, when it isn’t supposed to as per documentation
Are you sure?
By default, the Gradle plugin creates two separate task groups: one is the default one (`buildTypes.default`, which corresponds to`packageDmg`, `runDistributable`, etc). The other is the release one (`buildTypes.release`, which corresponds to `packageReleaseDmg`, `runReleaseDistributable`, etc). Only release packaging tasks run ProGuard by default.
I’ve just checked that, on a sample project. All in all, `packageDmg` is not expected to be influenced by `buildTypes.release` settings.
Can you share a reproducer project or at least a gradle script and proguard settings file?

<@U0BLUPVPY> I have just re-checked: when I was running `packageDmg` I was then still using by my mistake the files in the `binaries/main-release` directory instead than the ones in `binaries/main`, so I can confirm that it is working as expected

so for now the issue seems to be purely proguard-side

yeah sorry for the false alarm in that regards :joy:

No worries. These types of issues tend to be quite confusing, but I am not sure, how to improve that.
BTW I recommend using `runReleaseDistributable` before packaging. It runs pre-packaged application just as it would run after installation.

Using `runReleaseDistributable` is just faster, than running `packageReleaseDmg`, then installing the dmg, then running the installed app.

ah I see, so it still generates the dmg or msi but it also runs exactly the same packaged app immediately

&gt; it still generates the dmg or msi
It does not package the dmg, but uses the same content.

The whole pipeline works like this:
`createRuntimeImage` (uses jlink to create minified JDK image) &lt;- `createDistributable` (creates an application image: bundles JDK and jars together).
Then `runDistributable` runs the application image created by `createDistributable`,
whereas `packageDmg`/`packageMsi`  packages the same image into an installer.