NixOS JVM - Public Room Timeline

	NixOS JVM	119 Members
		26 Servers

Load older messages

Sender	Message	Time
16 Jul 2025
msgilligan	This is totally uncharted territory for me.	06:39:38
msgilligan	Wondering if I should create an issue and/or a draft PR. I think the issue might be a good place to discuss requirements and features in a way that can get people involved.	06:41:55
msgilligan	I was thinking it might make sense to define some kind of JDK specific metadata that could live in the root directory of each JDK package-set.	06:42:47
msgilligan	For example, I currently have definitions of which versions are supposed to be supported by each JDK and whether their is a default (e.g. `corretto` doesn't exist, but `zulu` defaults to `zulu21`.	06:45:41
msgilligan	* For example, I currently have definitions of which versions are supposed to be supported by each JDK and whether there is a default (e.g. `corretto` doesn't exist, but `zulu` defaults to `zulu21`.	06:46:00
msgilligan	* For example, I currently have definitions of which versions are supposed to be supported by each JDK and whether there is a default (e.g. `corretto` doesn't exist, but `zulu` defaults to `zulu21`.)	06:46:12
msgilligan	I'd rather have a list of JDK root paths and query them for metadata (perhaps with defaults for package-sets that haven't implemented the metadata yet)	06:48:05
msgilligan	Could look for the recurse for derivations flag I don't know what this means.	06:48:31
msgilligan	Currently `jdk-dashboard.nix` and `jdk-dashboard.sh` are in `nixpkgs/maintainers/scripts` but I'm not sure that is the right place.	06:49:59
Infinidoge 🏳️‍⚧️	In reply to @msgilligan:matrix.org Could look for the recurse for derivations flag I don't know what this means. Generally on sets of packages, there is a specific attr (I forget which exactly) that is set to `true` to flag that functions should look through the attribute set for derivations	06:51:18
msgilligan	e.g. `corretto = { hasDefault = false; versions = [ "11" "17" "21"]; };` and `zulu = { hasDefault = true; versions = [ "11" "17" "21" "24"]; };`	06:51:34
Infinidoge 🏳️‍⚧️	I believe there should be more info attached to lib.recurseIntoAttrs	06:51:37
msgilligan	and I'm including `-` and `_` as a prefix in some versions as there is currently no consistent mechanism for concatenating name to version. e.g. `zulu21`, but `temurin-bin-21` and `graalvmPackages.graalvm-oracle_17`	06:54:17
msgilligan	We should probably look at what SDKMAN! does: https://sdkman.io/jdks	07:18:07
msgilligan	Note that they are using Temurin as their default JDK.	07:18:27
msgilligan	And of course, what I would like to be able to do is to view the versions of each Nixpkgs JDK and display it next to the latest version available for that JDK. We have updaters for some of the JDKs that will pull the latest versions from a server.	07:42:33
msgilligan	It looks like there is an API that can give that info for many distributions: https://github.com/foojayio/discoapi	07:43:14
msgilligan	I opened an issue for the "JDK dashboard Utility": https://github.com/NixOS/nixpkgs/issues/425860	18:10:28
msgilligan	I also set some of the metadata tags on this issue, let me know if I did that wrong.	18:27:11
17 Jul 2025
emily	they don't build their own JDKs, so this isn't really a comparable situation	13:06:52
emily	we already use Temurin as the "vanilla" binary build to bootstrap our OpenJDK source build, e.g.	13:07:08
emily	Temurin is "just" a vanilla-aiming OpenJDK build	13:07:54
emily	a distribution in itself	13:08:01
emily	it is standard for package collections, as distributors themselves, to compile their own OpenJDKs	13:08:24
emily	there is really not much magic in the build glue https://github.com/adoptium/temurin-build	13:09:08
emily	the value-add of Temurin is in providing the infra and testing and brand name, not the build logic	13:09:37
emily	which is why a separate Temurin source build makes no sense (either the Temurin build scripts are a good fit for us and we can use them in our OpenJDK source builds, or they would make the derivation less maintainable or less flexible and so we should keep driving the OpenJDK build on our own)	13:10:35
emily	the Temurin product is builds	13:11:07
emily	not sure if they even allow their trademark to be used for builds of OpenJDK that happen to use the same build scripts	13:11:20
emily	feel like the proliferation of near-identical OpenJDK distributions has led to a lot of confusion about what they actually are…	13:12:19

Show newer messages

Back to Room ListRoom Version: 6