Closed hsz closed 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
?
Indeed!
FTR, related issue: https://github.com/JetBrains/gradle-intellij-plugin/issues/1511
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?
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.
Ok, so let me give it a try…
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.
Just checked and it looks like the pkgs are already in there…you might want to check for example 17.0.9
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?
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.
Yep, just checked and it was missing the pkg installers...will add them...
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.
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!
Glad it worked out 👍🏻😁
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.