Add support for `mise` locations.

[koppor]

mise-en-place is asdf on stereoids: Runs well on Windows, macOS and Linux; has several backends. Can install JDKs more smoothly than sdkman.

mise support was wished at gradle, but I think, this plugin here is the more appropriate place?

• General issue: Add mechanism for different package managers to contribute their installed JVM toolchains gradle#29508
• mise issue: Auto-detection of installed toolchains by mise gradle#29355

[sschuberth]

While mise is a good replacement for asdf (or sdkman), what exact value does it bring to this plugin, as I doubt that it will offer more / different JDKs than already offered through this plugin / https://github.com/foojayio/discoapi?

[koppor]

While mise is a good replacement for asdf (or sdkman), what exact value does it bring to this plugin, as I doubt that it will offer more / different JDKs than already offered through this plugin / foojayio/discoapi?

I am thinking of bandwidth and disk space saving. I know that in these times one orders largers hard disks etc, However, I think, that "quick wins" for saving that would maybe save the acquisition of additional hard disks.

Spontaneous additional thought: Offline builds could be more easy. --> only mise is used to communicate with the outside world / files of mise are places inside the build machine from another machine. No need to take care about foojay's logic of placing JDKs.

---

Side track: https://www.linkedin.com/posts/peter-ely-9330aa22_userexperience-techfails-itstrategy-activity-7300812403804418048-GnzH?utm_source=share&utm_medium=member_desktop&rcm=ACoAAACCUVQBYmlu_A9exTiDRiuXB95v-LNYD4c

[sschuberth]

I am thinking of bandwidth and disk space saving.

If you think about reusing a local JDK that has already been installed via mise, then I believe this is the wrong project to ask. Instead, this should go to upstream Gradle, as Gradle already has built-in toolchain providers that check local directories for available JDKs.

However, this plugin extends the toolchain provider logic to also provide remote URLs to download / bootstrap JDKs from if no matching local JDK could be found.

[koppor]

However, this plugin extends the toolchain provider logic to also provide remote URLs to download / bootstrap JDKs from if no matching local JDK could be found.

Ah, thank you for the explanation.

As a consequence, this probably won't happen in this decade.

[sschuberth]

Instead, this should go to upstream Gradle

BTW, mise is already covered by gradle/gradle#29508 / gradle/gradle#29355... which you actually already commented on, as I just realized 😸

[koppor]

Instead, this should go to upstream Gradle

BTW, mise is already covered by gradle/gradle#29508 / gradle/gradle#29355... which you actually already commented on, as I just realized 😸

🥂

Fortunately, there is a workaround: https://github.com/JabRef/jabref/blob/fe09477893d7f4430cfd7da152b760e88e878ae7/.github/workflows/binaries-ea.yml#L188

However, I cannot tell all newcomers to use that workaround. But I think, we don't need that any more, since we don't need JDK-25-ea for our builds; JDK-24 is enough (again). Refs openjdk/jdk#21698 (comment)

[koppor]

which you actually already commented on, as I just realized 😸

Side track:

Here, my issue descrption renders as follows:

Maybe, it is because of https://github.com/fregante/github-issue-link-status - and without plugin, one does not see the link descriptions?

[koppor]

I know why I thought this could be part of foojay - because I only quickly read some text on the mise manual - https://mise.jdx.dev/lang/java.html#gradle-toolchains-detection