| 23 Nov 2024 |
 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 | 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 |
| Tomodachi94 (they/them) | In reply to@ami:the-apothecary.club
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 Looks like the Jenkins and Bloop modules only afaict | 02:03:22 |
| Tomodachi94 (they/them) | I'll probably update those later tonight, along with updating packages which have patches released for Gradle 8 | 02:15:27 |
| Ami | speaking of running plain java commands, is there any "good" way to use multiple java versions in the same environment, or at least get something similar to that? the most obvious answer to me seems like using nix-shell in one way or another | 02:23:14 |
| Tomodachi94 (they/them) | In reply to@ami:the-apothecary.club
speaking of running plain java commands, is there any "good" way to use multiple java versions in the same environment, or at least get something similar to that? the most obvious answer to me seems like using nix-shell in one way or another I don't think there's anything built-in, but my first thought was somehow prefixing the executables. Symlinks maybe? | 02:25:10 |
