While #321247 technically "fixed" JAR plugins, it fixed by creating a
broken symlink. The reason it wasn't causing issues before is because
the derivation before set `donFixup = true`, skipping the checks for
broken symlinks in the derivation.
Now that the fixup phase is re-enabled, this is causing the build to
fail if you have a JAR plugin like `wakatime`. Now the symbolic links
are correct, but I am not sure if this is working correctly or not.
There were 2 issues for usage of `jetbrains.plugins.addPlugins` in
darwin:
- Some IDE products have spaces in name (e.g.: "IntelliJ IDEA CE"). The
current code didn't escape or quoted the strings together, so it
failed during build
- After fixing the issue above, opening the resulting app bundle (e.g.:
`open result/Applications/IntelliJ IDEA CE`) would result in an error
because we modified the bundle but kept the old signature
This commit fixes both those issues, the first one by quoting the IDE
name using `lib.escapeShellArg` and the second one by using
`darwin.autoSignDarwinBinariesHook`.
In recent JetBrains releases, a `plugin-classpath.txt` made its
appearance. That file seems to be a cache of some kind that the IDEs
use to discover which plugins are bundled with an IDE release.
If that file is removed, there seems to be a fallback mechanism that
instead goes through the list of subdirectories in `plugins`. That
works rather better for us, as we don’t know how to generate a
`plugin-classpath.txt`.