| 23 Nov 2024 |
 Tomodachi94 (they/them) | Confirmed to not break anything in-tree | 20:38:28 |
| Tomodachi94 (they/them) | * Oh, looks like there's a live "fork" owned by fzakaria, the original dev: https://github.com/fzakaria/mvn2nix | 20:50:04 |
| Tomodachi94 (they/them) | In reply to@emilazy:matrix.org
we really ought to just shim in our own local FS repository and build everything from source but 🙃 Can we assume anything about the build system the dependencies use? Or would we have to determine that first | 20:51:49 |
 emily | I assume every dependency would build with whatever its build system is and spit out jars that we integrate in the maven repository format or such | 20:56:20 |
| Tomodachi94 (they/them) | Interesting. Looks like one can specify a classpath through META-INF/MANIFEST.MF inside of JARs, to allow Java libraries to find their dependencies automatically... in theory | 22:12:05 |
| Tomodachi94 (they/them) | Interesting. Looks like one can specify a Class-Path through META-INF/MANIFEST.MF inside of JARs, to allow Java libraries to find their dependencies automatically... in theory | 22:12:22 |
| Tomodachi94 (they/them) | (ant-contrib is a 20-year-old beast) | 22:18:21 |
| Tomodachi94 (they/them) | Yes, it has had no releases since 2006 | 22:27:48 |
| Tomodachi94 (they/them) | There is a newer fork last updated two or so years ago | 22:28:02 |
| Tomodachi94 (they/them) | In reply to@tomodachi94:matrix.org
Interesting. Looks like one can specify a Class-Path through META-INF/MANIFEST.MF inside of JARs, to allow Java libraries to find their dependencies automatically... in theory ... and the jar utility has a specific option for intelligently amending the manifest | 23:00:05 |
| 24 Nov 2024 |
| Tomodachi94 (they/them) | In reply to@emilazy:matrix.org
yeah, poke me in a few days (if everything is ready) and I'll try to look. trying to take it easy for a few days (we'll see if I manage 🙃) Does this count as a few days? 🙃 | 00:00:33 |
| emily | I'll try and look some time tonight | 00:08:06 |
| Tomodachi94 (they/them) | In reply to@emilazy:matrix.org
I'll try and look some time tonight No rush if I was too soon | 00:14:08 |
| emily | no worries :) | 00:15:20 |
| Tomodachi94 (they/them) | Currently hunting for packages that provide Ant task providers and adding a symlink in the spot expected by ant.hook | 01:57:58 |
| Tomodachi94 (they/them) | Found a few thanks to nix-index. Will PR that in later | 04:34:52 |
| Tomodachi94 (they/them) | (Also, there are so many packages that have Ant in their output, but don't need it to be there) | 04:38:51 |
| Tomodachi94 (they/them) | Wondering if we should drop the programs.java NixOS module, since it's impure and only has two in-tree consumers (packages should make a wrapper that calls jdk/jre, developers should be using devShells) | 22:25:12 |
| Tomodachi94 (they/them) | Pinging @FliegendeWurst @chayleaf @Infinidoge 🏳️⚧️ for input | 22:28:18 |
| Tomodachi94 (they/them) | Pinging @FliegendeWurst @chayleaf @Infinidoge 🏳️⚧️ for input (others welcome to chime in too, of course) | 22:28:37 |
 Infinidoge 🏳️⚧️ | The main benefit of the Java module is that it let's end consumers emulate a more standard Linux distribution for running programs that use Java internally, so I don't think it being impure is strictly a reason to remove it in this case | 22:30:00 |
| Infinidoge 🏳️⚧️ | At minimum though in-tree consumers can be rewritten away from it | 22:30:25 |
| Infinidoge 🏳️⚧️ | * The main benefit of the Java module is that it lets end consumers emulate a more standard Linux distribution for running programs that use Java internally, so I don't think it being impure is strictly a reason to remove it in this case | 22:30:41 |
| Infinidoge 🏳️⚧️ | It's a similar position to nix-ld, albeit less critical | 22:31:27 |
 FliegendeWurst (@GPN23) | The binfmt hooks seem only marginally useful to me. The .class one only really works if the class depends solely on its own package. | 22:34:11 |
| Tomodachi94 (they/them) | For starters I'll add it to our ci/OWNERS section, then we can change in-tree consumers to the makeWrapper pattern later | 22:36:37 |
| Tomodachi94 (they/them) | https://github.com/NixOS/nixpkgs/pull/358840 | 22:55:02 |
| 25 Nov 2024 |
| Tomodachi94 (they/them) | In reply to@tomodachi94:matrix.org
I'm going to look into which of our packages use Gradle 7 and try updating or submitting patches for a newer Gradle, to hopefully make the future deprecation of Gradle 7 smoother Made a tracking issue for this, so our future drop+upgrade can go much smoother than the gradle_6 one: https://github.com/NixOS/nixpkgs/issues/358845 | 00:11:01 |
| Tomodachi94 (they/them) | * Made a tracking issue for this, so our future drop+upgrade can go even smoother than the gradle_6 one: https://github.com/NixOS/nixpkgs/issues/358845 | 00:31:03 |
 Ami | In reply to @tomodachi94:matrix.org
Wondering if we should drop the programs.java NixOS module, since it's impure and only has two in-tree consumers (packages should make a wrapper that calls jdk/jre, developers should be using devShells) i haven't looked at what it does or what needs those changes, but i do use plain java commands at times, sometimes for development, sometimes to run some jar that most likely doesn't have a nixpkgs equivalent | 01:53:28 |
