[Q] Guidance for instrumenting(?) Toolchain Resolvering to use "on premise" url's?

Help/Discuss
1

Hi there :waving_hand:

i am considering my options how to supply gradle builds with jdk’s which are coming from my own sources via the gradle toolchain resolving mechanics.

  • How do other ppl work with toolchain resolving jdk’s from “on premise” download-locations?
  • Is there a simple solution, how i might be able to configure download URLs for the zips myself somehow? (say, some easily customized existing fork of the foojay resolver + creating a configuration file that lists available jdk-dl-options and their respective dl-location?)

After

  • having read Toolchain Resolver Plugins
  • having searched around a bit and having found the foojay resolver plugin
  • (and as an interesting - but derailing, and therefore ignorable - sidetrack, having read multiple findings for the IBM_SEMERU vendor deprecation actions necessary to fix things :nerd_face: )

my understanding (which might be flawed) is now as follows:

  • gradle toolchain resolvers out-of-the-box use the foojay resolver under the hood(?)
  • the foojay toolchain resolver targets the foojay discoapi to get the url’s for the download locations
  • this would not be feasible to use in my case because this triggers remote api calls + downloads

Therefore i thought, i might ask this question(s) here … because it would be super nice, if i would not need to re-invent everything, by maintaining my own fork of the foojay toolchain resolver plugin :sweat_smile: )

Please, if possible, be easy with my use of words, my descriptions might be “flawed in the wordings” :innocent:

cheers
Daniel

2

gradle toolchain resolvers out-of-the-box use the foojay resolver under the hood(?)

No, it does not use anything under the hood.
If you want to use the foojay resolver, then you have to apply the foojay resolver plugin and configure a repository that uses it,
or you need to apply the foojay conventions plugin that does exactly those two steps for a standard setup.

the foojay toolchain resolver targets the foojay discoapi to get the url’s for the download locations

Yes

this would not be feasible to use in my case because this triggers remote api calls + downloads

Then just register your own resolver instead.

plugins {
    `jvm-toolchain-management`
}

abstract class Foo : JavaToolchainResolver {
    override fun resolve(request: JavaToolchainRequest): Optional<JavaToolchainDownload> {
        return Optional.of(JavaToolchainDownload.fromUri(URI("https://foo.bar")))
    }
}

interface JavaToolchainResolverRegistryProvider {
    @get:Inject
    val javaToolchainResolverRegistry: JavaToolchainResolverRegistry
}

extensions.create<JavaToolchainResolverRegistryProvider>("foo").javaToolchainResolverRegistry.register(Foo::class)

toolchainManagement {
    jvm {
        javaRepositories {
            repository("foo") {
                resolverClass = Foo::class.java
            }
        }
    }
}

(The JavaToolchainResolverRegistryProvider and extension stuff is just to get hold of the JavaToolchainResolverRegistry instance in the settings script, if you would write it as settings plugin, you would simply let Gradle inject that.)