| 1 Jan 2025 |
linsui | When updating jabref I encountered another problem. It added embeded postgresql. The packaged postgresql doesn't run on NixOS. I thought I should replace it with the postgresql in nixpkgs. Should I override mitmCache somehow? | 16:37:46 |
linsui | Or I should replace the jar in lib/? | 16:38:09 |
emily | I think you can patch the Gradle file to use a file dependency and just inject the path to our .jar | 16:39:24 |
emily | and then regenerate the mitm-cache | 16:39:28 |
linsui | Then I thought I need to add the patch into the FOD. I thought this is not necessary. | 16:45:39 |
emily | it'll change what dependencies Gradle calculates, so you can patch the Gradle file and then update the mitmCache JSON | 16:46:04 |
linsui | Does fetchDeps work with postPatch? | 16:46:42 |
linsui | So that the mitmCache package will be smaller? | 16:47:47 |
emily | it won't include the broken Postgres | 16:51:23 |
emily | not sure :/ | 16:51:48 |
emily | it uses some srcOnly stuff | 16:51:49 |
emily | it may be harmless to have the mitmCache entries though | 16:51:49 |
emily | I think patching the Gradle file is the correct way in any case | 16:51:50 |
linsui | Yep :) | 16:53:14 |
linsui | How should I deal with transit deps of it? I need to package https://github.com/zonkyio/embedded-postgres and remove the dep of the embeded pg binaries. But it has other maven deps. | 18:18:52 |
linsui | * How should I deal with transitive deps of it? I need to package https://github.com/zonkyio/embedded-postgres and remove the dep of the embeded pg binaries. But it has other maven deps. | 18:19:31 |
emily | ah, I think I misunderstood: I thought you wanted to replace some Java PostgreSQL binding it used with one we already have packaged in Nixpkgs (as part of the PostgreSQL package, say) | 18:19:59 |
emily | but this is a library that embeds and spawns Postgres itself? | 18:20:05 |
emily | that's unfortunate, I wonder if we can convince the library to use our own Postgres… | 18:20:24 |
linsui | Yes, it packages pg binaries in its deps. | 18:20:32 |
linsui | With patches we can do anything. :) | 18:20:47 |
emily | re: transitive deps, I think you should be able to just use our standard Maven builders? I believe those work in the usual FOD hash way and you could inject that into jabref | 18:20:58 |
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 |