| 1 Jan 2025 |
 emily | but I'm not entirely sure. Java dependency handling is a mess and I don't trust it. | 18:21:08 |
 linsui | It unzip the pg binaries into a tmp dir and run it. I'll patch it to run pg from nixpkgs. | 18:21:45 |
| emily | in true Java fashion, the library has an interface PgBinaryResolver. maybe you could patch jabref to implement that interface and use it, and skip patching the library entirely | 18:21:53 |
| linsui | And this lib will use the implementation provided by jabref? | 18:26:03 |
| emily | I think it depends on how jabref uses the library :S | 18:26:51 |
| emily | you can pass a PgBinaryResolver to EmbeddedPostgres | 18:27:10 |
| emily | if it uses EmbeddedPostgresRules.singleInstance() I think you need to do something like new SingleInstancePostgresRule().customize(builder => builder.setPgBinaryResolver(…)) instead | 18:28:41 |
| linsui | Ah, I understand now. :) Thanks! This is a good idea! | 18:30:09 |
| emily | ideally the library would just let you set an environment variable or something to give it a prebuilt Postgres but I guess this is more Java 😅 | 18:30:54 |
| linsui | I tried to find such a env var but it seems there is no such thing... | 18:31:39 |
| emily | the closest thing I can find is that it includes the distro name when looking for the tarball which it looks up in some kind of Java classpath resources thing … but I don't know if you can inject into that without patching the library | 18:32:30 |
| emily | https://github.com/zonkyio/embedded-postgres/blob/ed189edde855b25340245b7fac5a7fe6a5a497a6/src/main/java/io/zonky/test/db/postgres/embedded/DefaultPostgresBinaryResolver.java | 18:32:41 |
| emily | logger.error("No postgres binaries found, you need to add an appropriate maven dependency " +
"that meets the following parameters - system: '{}', architecture: '{}' " +
"[https://github.com/zonkyio/embedded-postgres#additional-architectures]", system, architecture);
| 18:32:53 |
| emily | it seems like maybe you could construct a fake package just to provide our own PostgreSQL, in a way that this can find | 18:33:07 |
| linsui | I guess I need to package the pg binaries into a txz file then put it into a jar... | 18:37:51 |
| emily | yes, might be worse than the PgBinaryResolver approach | 18:38:52 |
| 3 Jan 2025 |
|  @gotha:matrix.org joined the room. | 09:25:31 |
| 4 Jan 2025 |
| linsui | I finally choose this method. Ugly but easy. https://github.com/NixOS/nixpkgs/pull/370839 | 12:04:52 |
| emily | would you like me to have a go at fixing OpenJFX WebKit so you can skip some of the hacks there? | 14:12:04 |
| emily | I wonder if we should make that bundled Postgres thing a package in case there are other things in the tree that want to use it (but maybe YAGNI) | 14:12:55 |
| linsui | If other packages also use it, maybe we can make the java part a package so that it can use the postgresql from nixpkgs directly. | 14:38:51 |
| linsui | Yes, it would be great! :) | 14:39:20 |
| linsui | Is it possible to make the jdk with jfx reuse the headless package (or it already does this)? it seems if I have a package using headless jdk and a package using jfx, I'll have two jdk installed. | 14:43:46 |
| emily | we should split OpenJFX out of the JDK entirely | 14:49:41 |
| emily | AIUI there's no need to bundle it in and upstream are moving to deprecate it | 14:49:49 |
| emily | I believe it can "just" be a normal Java package (something something jlink?) | 14:49:57 |
| emily | I don't really know enough about Java to be the right person for the job but I might end up doing it anyway 😅 | 14:50:17 |
| emily | it would simplify the derivations quite a bit | 14:50:26 |
| emily | but yes, we currently bootstrap a new JDK for it | 14:50:38 |
| emily | see e.g. https://bugs.openjdk.org/browse/JDK-8294095 | 14:50:59 |
