Offer AdoptOpenJDK in addition to Zulu #13
Comments
|
OpenJDK should be the default instead a vendor's specific distribution, but there should be an option to opt into a specific vendor(azul, amazon, etc...) |
|
I hope I am not hijacking this thread and I'll create a separate issue if requested. So, wget is used to pull a JDK with JavaFX. The workflow then calls ls and shows the .gz file, but during the setup-java action it says the file specified by jdkFile does not exist. Am I correctly specifing the jdkFile? This is the repository I am trying to use with Github Actions: https://github.com/onebeartoe/java-libraries/commit/88b3fdc9b76dc6ba366773f75d6683dfc0142ef5/checks |
|
One more vote for OpenJDK being an option! |
|
Whoops, sorry I missed this, for some reason my alerts for this repo got turned off 😳 I actually originally wanted to do this using OpenJDK, but ran into an issue that I couldn't find a good solution to. Basically the OpenJDK download urls aren't consistent and there's not a well defined distro. So for example, here are the Linux download urls for a some of the versions, pulled from here: Everything below that would be downloaded from oracle, and I think we run into licensing issues there that make normal curl downloads challenging. I'm open to solutions there, but have concerns about anything that requires us to hardcode a bunch of urls and/or update every time a new version is released. Note that if you need openJDK you can do this by doing something like: That's a big part of the reason we kept the |
|
Is it an option to |
|
One of the main points of this repo is to stay platform agnostic so you don't need a different workflow for each OS. |
|
adoptopenjdk.net is nowaday's place to go for OpenJDK builds. They even offer an API that gives you access to all metadata and binaries you need https://api.adoptopenjdk.net/ |
|
Here is the list of the platforms supported by adoptopenjdk.net in a human readable form: https://adoptopenjdk.net/supported_platforms.html |
|
One other options of getting the java version could by by using https://github.com/sormuras/bach/blob/master/install-jdk.sh by @sormuras. It is quite powerful and allows downloading different JDKs |
|
@damccorm, I tried using the jdkFile like you mentioned above. But the build still gives a 'no such file' error and fails. Here is the build: https://github.com/onebeartoe/java-libraries/commit/6b75c16018a68416aa3c3be1ee171d6058c7ebc7/checks Is there something missing there to use the jdkFile option for actions/java-setup? |
|
@onebeartoe Huh, that's a surprising error - could you open a separate issue to track that? Would rather keep this conversation focused to offering openJDK since that's a separate topic 😄. I'm not 100% sure, but checkout might change the working directory - so maybe try running Concerning the larger thread: I haven't had a chance to look into adoptopenjdk.net or https://github.com/sormuras/bach/blob/master/install-jdk.sh in depth yet, but am very open to using one of those/think we probably want something along those lines. At a glance, it looks like adoptoopenjdk.net offers cross plat linux/mac/windows support but install-jdk.sh only offers linux/mac, so I'm more inclined to use a solution that directly targets adoptopenjdk.net. If I'm missing something there please let me know. |
|
@damccorm It turns out that checkout was clearing the pwd contents. This is the bulid where I noticed: https://github.com/onebeartoe/java-libraries/runs/200793085 So I moved the JDK download to after checkout. And here is the successfull setup-java using jdkFile. https://github.com/onebeartoe/java-libraries/commit/07d31eb5ae0f9649ea29a552fc1ea9460de07b44/checks Again I didn't meant to hijack this thread, and I didn't open a separate issue since I noticed what was going on with the order of the call to setup-java with jdkFile. Thanks |
|
@stephenmichaelf probably makes sense for you to take this one. IMO we should do this using https://api.adoptopenjdk.net/ |
|
Adding other JDK distribution options and letting people pick whichever they want may be a good idea. But I'd like to highlight that Zulu Community is a build of OpenJDK. Zulu is no more "vendor-specific" than e.g. AdoptOpenJDK is "IBM specific" (IBM sells support for AdoptOpenJDK builds). Zulu is the longest-standing, free, 100% OSS build of OpenJDK available for Linux, Windows, and MacOS. It has a full, well-maintained, and uninterrupted history of having good, free builds of every single version of OpenJDK thru 6, 7, 8, 9, 10, 11, 12, and now 13, over the past ~6 years. This wide coverage and commitment to consistent delivery is why you can currently test Java CI on Github Actions for fixed versions like e.g. Java 7u181 (7.0.181), Java 8u131 (8.0.131), Java 9.0.4, and Java 12.0.2 Just by specifying their versions, and will be able to continue to do so uninterrupted side by side with various form of "latest" (11 or 11.0.x vs. 11.0.3). The OpenJDK project is a source code project (and the OpenJDK name is trademarked by Oracle). All OpenJDK binaries come from some form of downstream curated builds of OpenJDK version distributions. Zulu is simply the longest standing one, and by far the one with the most builds and versions available and reliably maintained. But there are others (e.g. Corretto, Liberica, SAP machine, etc. which are TCK tested, and some others that are not). It's a happy, multi-distro world. Just like Linux. And the numbers of free OpenJDK distros seems to be growing and flourishing, which is a good thing. That's why adding choices for specifying an OpenJDK distro (via e.g. "distro: zulu", "distro: corretto" or "distro: liberica", "distro: adopt", "distro: sap") is probably a good idea. We'd be happy to collaborate on that. |
|
We've now switched to using Zulu since it is provided out of the box. However, my biggest reason for suggesting something like install-jdk.sh was the fact that it supports installing the latest EA JDKs. This is extremely useful for libraries out there that want to test out against a suite of JDKs including latest and greatest via matrix builds. We (open source maintainers) are already spread thin so having some non hacky way for us to achieve this in our CI would be more than welcome 😀 |
|
I'll work to make sure the Zulu CDN has EA builds available to address this latest note. The spelling of the version (given the current logic in the action) will probably need to be 14.0.0-ea, or 14.0.0-ea+bXX. I believe that we can match that in the CDN to make things work. |
|
In the meantime, you may use this as a work-around: jdk-14-ea:
runs-on: ubuntu-latest
steps:
- name: 'Download latest-and-greatest JDK 14-ea'
run: |
DOCKERFILE=${HOME}/jdk-14.dockerfile
wget https://github.com/docker-library/openjdk/raw/master/14/jdk/Dockerfile --output-document ${DOCKERFILE}
JAVA_URL=$(cat ${DOCKERFILE} | sed -n 's/ENV JAVA_URL //p')
JAVA_VERSION=$(cat ${DOCKERFILE} | sed -n 's/ENV JAVA_VERSION //p')
wget --directory-prefix ${HOME} ${JAVA_URL}
echo ::set-env name=JAVA_VERSION::${JAVA_VERSION}
echo ::set-env name=JDK_FILE::"${HOME}/$(basename ${JAVA_URL})"
- uses: actions/setup-java@v1
with:
java-version: "${{ env.JAVA_VERSION }}"
jdkFile: "${{ env.JDK_FILE }}"
- run: java -versionCopied from: Workflow run: https://github.com/sormuras/bach/runs/352060818 PS: Replace |
|
I wrapped the inline-script into my first docker action: https://github.com/sormuras/download-jdk Usage: - uses: sormuras/download-jdk@master
id: jdk
with:
feature: 14
- uses: actions/setup-java@v1
with:
java-version: ${{ steps.jdk.outputs.version }}
jdkFile: "${{ steps.jdk.outputs.file }}"
- run: java --version |
|
Ok. We've populated the Zulu CDN with 14-ea, with filename spelling that works with setup-java's parsing rules. The following seems to work directly now: We will start updating EA builds there going forward. |
Note that you have to use the -ea part in the name for EA versions. Per semver parsing rules (see e.g. https://github.com/npm/node-semver or https://github.com/semver/semver/blob/master/semver.md) version specifications that do not specify a pre-release part of the version (a "-" following the X.Y.Z part) will not match to pre-release versions. I believe that this is a good thing (TM). |
Very nice! That renders my new action almost superseded on the day it was created. "I believe that this is a good thing (TM).", though, as
Which is perfectly fine. |
|
Sometime in the future I would like to add support for specifying a distro in the YAML That way it would be easily extendable to other distributions of Java within this action. Something like what is described here: #13 (comment) Super busy right now 😕 But this is on my bucket-list of things for the future. Thanks in the meantime @giltene for adding EA builds to the Zulu CDN! |
|
I'd be happy to collaborate on adding additional distro options when you get around to working on it. Here are openjdk distros (with likely names) that I see people asking about the most are:
I expect that parsing the semver-variant syntax in a way that will work robustly and similarly with the contents available for each distro will take some effort, but it is a doable thing. |
|
I've created a pull request with an ADR (architecture decision record) that outlines a roadmap & plan for the Any feedback, ideas or suggestions will be greatly appreciated: #97 |
dmitry-shibanov
added
the
feature request
* add initial tests for jdkfile, zulu and base class * add fail-fast: false * work on possible fix * fixing tests * fixing format and create create release * add possible fix * V malob/adopt tests (#2) * implement adopt tests * fix nitpicks * return debug back * remove to-do * remove workflow file * resolving a part of comments * add changes * resolving a part of comments * work on resolving comments * resolve comment * fix calls * resolving comments * fixing tests * add method with support build version * improve tests (#3) * improve tests * Update installer.ts * fix version resolution * Update index.js * remove import * resolving comments * remove extra describe and afterEach Co-authored-by: Maxim Lobanov <v-malob@microsoft.com>
|
Hello everyone! |
|
Hello! README for v2-preview: https://github.com/actions/setup-java/tree/v2-preview |
|
@maxim-lobanov the action works fine, however we require this fix too: #82 in order for this action to be useful to us... |
|
@davidkarlsen , your proposal makes sense to me and looks like it won't be a breaking change since we default new property to true by default. |
|
@davidkarlsen , @joschi , I have prepared PR from my side because moving changes to V2 can be tricky (hope you don't mind): #136 |
|
@maxim-lobanov no prob - it's not my PR - I just need the feature :-) Nice to see it moving forward. |
|
@davidkarlsen Go ahead, please. 😃 |
|
#136 was merged. We are going to release v2 stable by the end of next week but we would be very appreciate for any testing of |
|
@maxim-lobanov tested - it works fine! |
|
Are there any plans to add |
|
Hello everyone! steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v2
with:
distribution: 'adopt'
java-version: '11'
- run: java -cp java HelloWorldAppPlease find more details in repo readme. |
|
@MarcelCoding , no plans for now but I think it is something that we can consider. Feel free to create a feature request |
I've created one: #155 |
|
Hello everyone. On Monday 5th April we released |
|
update |
and others
Should be downloadable e.g. from https://adoptopenjdk.net/
The text was updated successfully, but these errors were encountered: