foojayio / discoapi

The foojay discovery api (discoapi) is made to discover java packages (jre/jdk) from different distributions.
GNU General Public License v2.0
107 stars 12 forks source link

How to test distribution definition? #93

Closed hsz closed 6 months ago

hsz commented 6 months ago

Hi, @HanSolo!

In the case of JBR (JetBrains Runtime), we need to point to the JCEF variant by default, but a "plain" one is used instead. The reason for that is that JBR is used for testing plugins and running JetBrains IDEs. JCEF presence is required.

The change is simple, but I wonder what the valid flow for testing distributions, like src/main/java/io/foojay/api/distribution/JetBrains.java is?

As soon as I get the testing environment working, I will prepare a relevant pull request.

HanSolo commented 6 months ago

Ok so if I get it right you need the jbr_jcef variant instead of the jbr variant? Meaning to say instead of for example getting the jbrsdk-17.0.9-linux-aarch64-b1087.11.tar.gz you need the jbrsdk_jcef-17.0.9-linux-aarch64-b1087.11.tar.gz?

hsz commented 6 months ago

Indeed!

FTR, related issue: https://github.com/JetBrains/gradle-intellij-plugin/issues/1511

HanSolo commented 6 months ago

Ok, in the meantime I've already prepared something for that and will test it. If it will work, I could make it available. The question is if I should also change all the existing ones, which will take longer or if I should just start from now? Thoughs?

hsz commented 6 months ago

That sounds great, thank you! As for the question - the linked issue implies that JCEF is missing when referring to the JBR17 if one uses JvmVendorSpec.JETBRAINS as a JVM Toolchain vendor. However, we point always to the latest release, so there's probably no need to cover previous releases.

HanSolo commented 6 months ago

Ok, so let me give it a try…

HanSolo commented 6 months ago

I'm currently run a deployment of the new version which means that future versions of the JetBrains SDK should be available incl. JCEF. Dependent on when they will publish the next updates they should appear in the API. In case they won't, please let me know.

HanSolo commented 6 months ago

Just checked and it looks like the pkgs are already in there…you might want to check for example 17.0.9

hsz commented 6 months ago

Thank you for a quick change, Gerrit!

However, when requesting Disco API with archive_type=pkg: https://api.foojay.io/disco/v3.0/packages?distribution=jetbrains&package_type=jdk&latest=available&version=17&operating_system=macos&architecture=aarch64&archive_type=pkg

It shows some older releases. But with archive_type=tar.gz, I can see a single latest release, 17.0.9+108711 in the JCEF variant: https://api.foojay.io/disco/v3.0/packages?distribution=jetbrains&package_type=jdk&latest=available&version=17&operating_system=macos&architecture=aarch64&archive_type=tar.gz

How is that?

HanSolo commented 6 months ago

The JetBrains packages that I've found are only available as tar.gz (Linux and Macos) and zip (Windows). If you ask the api for the archive_type=pkg and latest available, it will return the latest available macos pkg it finds. In this case there have been no pkg installers with the jbsdk_jcef but only tar.gz. I will check again if I also look for pkg files and if not will add them to the search.

HanSolo commented 6 months ago

Yep, just checked and it was missing the pkg installers...will add them...

HanSolo commented 6 months ago

Currently deploying a new version which contains the pkg too, was my fault, but in my test instance they are already there, so it seems to work correctly now. Might take another day before they will show up in the api due to update intervals etc.

hsz commented 6 months ago

Awesome! Thank you, Gerrit! I just tested it, and API responses with proper data for both archive types — and it shows the latest available JBR version in the JCEF variant.

I tested that also in a Gradle-based project. With:

kotlin {
    jvmToolchain {
        languageVersion = JavaLanguageVersion.of(17)
        vendor = JvmVendorSpec.JETBRAINS
    }
}

and the org.gradle.toolchains.foojay-resolver-convention plugin applied, Gradle fetched the proper JBR into:

/Users/hsz/.gradle/jdks/jetbrains_s_r_o_-17-x86_64-os_x/jbrsdk_jcef-17.0.9-osx-x64-b1087.11

I appreciate your help on that. Cheers!

HanSolo commented 6 months ago

Glad it worked out 👍🏻😁