| 6 May 2026 |
 msgilligan | So for a normal Java build there should be no paths in any of the JARs. | 17:16:22 |
| msgilligan | I've also seen builds use the installToMavenLocal task with the destination directory overriden to produce a set of distribution JARs. | 17:17:06 |
| msgilligan | Something like this might also be the way to create a FOD with all the input dependencies for a Maven or Gradle package. | 17:18:24 |
| msgilligan |
I doubt it would be easier to publish from Nix
I just finished telling you that I'm a Matrix-using, Signal-using, Scheme-experimenting, Java 8 developer, former COBOL programmer, who enjoys writing Nix derivations. Do you think I'm looking for easy? 🤣
I like the idea of being able to have a 1-1 mapping between what is on Maven Central and a Nix derivation and I feel that (might) be worth the extra effort.
| 17:21:19 |
 Benedikt Ritter (britter) | Are you doing this all in your spare time? 😅 | 17:57:39 |
| Benedikt Ritter (britter) | Sounds sensible, although I'm not a fan of jreleaser due to its dependency footprint. | 17:58:27 |
| msgilligan | At the moment, working on bitcoinj and secp256k1-jdk is my full-time, unpaid project. And part of that is working towards getting those builds to be bootstrappable via Nix. I am a day or two away from a milestone release of secp-jdk (shortname) and will be trying to get a grant to continue work. | 18:13:56 |
| msgilligan |
I'm not a fan of jreleaser due to its dependency footprint.
I noticed that, too and share your concern.
| 18:14:36 |
| msgilligan | * At the moment, working on bitcoinj and secp256k1-jdk is my full-time, unpaid project. And part of that is working towards getting those builds to be bootstrappable via Nix. I am a day or two away from a milestone release of secp-jdk (shortname) and will be trying to get a grant to continue work. | 18:16:14 |
| msgilligan | But jreleaser is in Nixpkgs: https://search.nixos.org/packages?channel=unstable&query=jreleaser | 18:53:26 |
 dish [Fox/It/She] | also a second thing I'm looking at for after bootstrapping work is done(so very long-term) is to integrate AQAVit testing into the nixpkgs JDK build process(minus performance testing because build hardware can be very different of course) | 19:26:23 |
| dish [Fox/It/She] | the AQAVit test suite seems to be very weird to run offline though | 19:26:35 |
| dish [Fox/It/She] | * the AQAVit test suite seems to be very difficult to run offline though | 19:26:50 |
| dish [Fox/It/She] | * the AQAVit test suite seems to be very difficult to run offline though
(and frankly it's not 100% guaranteed that AQAVit would help us, but could help discover any potential Nix-specific bugs in full source JDK build chains) | 19:29:22 |
| dish [Fox/It/She] | * also a second thing I'm looking at for after bootstrapping work is done(so very long-term) is to integrate AQAVit testing into the nixpkgs JDK build process(minus performance testing because build hardware can be very different of course)
to elaborate slightly more, I'd only run this on end-user JDKs that we actually give to users as usable, not any intermediate ones such as jdk9/10 | 19:39:31 |
| msgilligan | I took a look at that, too. It seemed like a big project, though. | 20:27:52 |
| msgilligan | What I think would help with JDK maintenance is to have some modular filesystem schemas and basic utility tests that can run from Nix CI. i.e. a library that can be used test multiple JDKs. It seems like there is currently some duplication of effort for this on the individual JDK packages. | 20:30:07 |
| 8 May 2026 |
|  whispers [& it/fae] joined the room. | 19:02:58 |
|  Benedikt joined the room. | 19:03:32 |
|  Bart joined the room. | 19:35:39 |
| dish [Fox/It/She] | In reply to @msgilligan:matrix.org
What I think would help with JDK maintenance is to have some modular filesystem schemas and basic utility tests that can run from Nix CI. i.e. a library that can be used test multiple JDKs. It seems like there is currently some duplication of effort for this on the individual JDK packages. so, looking towards this, I think the best thing we can do at the moment for increased test coverage is to work towards building JTReg, since the openjdk source code includes tests we can run with JTReg which do not require additional test downloads(unlike AQAVit) | 22:22:04 |
| dish [Fox/It/She] | I do also agree there's potential to reduce the amount of duplication in packages, which I'll look into first. | 22:22:32 |
| 9 May 2026 |
|  André Lima joined the room. | 11:42:28 |
| Benedikt Ritter (britter) | https://github.com/NixOS/nixpkgs/pull/484741 rebuild-linux:1001-2500 🫠 | 14:03:23 |
| Benedikt Ritter (britter) | @infinidoge:inx.moe you said it's possible to use ofborg to run these massive rebuilds, because we can't expect everybody to have machine to run nixpkgs-review on such massive changes.
How does that work? Just @ofborg test <package-name>? That's not the same running nixpkgs-review though. | 14:11:10 |
| Benedikt Ritter (britter) | From https://github.com/NixOS/ofborg:
Be gentle; try not to run mass rebuilds or massive builds (like Chromium) on it.
😅
| 14:15:19 |
| dish [Fox/It/She] | here's a question. do we need the src.zip that is included in the JDK outputs? That just contains the source code, and it's not needed at runtime afaik. In openjdk 25, it's 53MB, which we could get rid of to shrink closure sizes slightly. | 17:33:10 |
| Benedikt Ritter (britter) | Sounds good to me. I doubt that it's needed. But I don't know 🤷♂️ | 17:44:19 |
| dish [Fox/It/She] | I'm not sure as well, which is why i asked here 😅 | 17:47:02 |
 Infinidoge 🏳️⚧️ | It might be required for inspecting the definitions of Java objects | 18:15:21 |
