Use AdoptOpenJDK as JDK Tool download source

[Sverre Moe]

Now that Oracle has shut down any commercial use of their JDK, Jenkins should add option to download JDK from AdoptOpenJDK

Install automatically
    Extract *.zip/*.tar.gz
    Install from java.sun.com
    Run Batch Command
    Run Shell Command

Now that the JDK from Oracle cannot be used in production we need another source.

Install from AdoptOpenJDK

https://adoptopenjdk.net/

[Devin Nusbaum]

There is some relevant discussion in https://issues.jenkins-ci.org/browse/JENKINS-54305 that may be interesting to you.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/6a0fc33b-e4b4-4c06-9674-2c49218617fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sverre Moe]

Thanks for the link. Good to see that they are looking into it. Hope it doesn't take to long.

[Martijn Verburg]

Hi all,

I help run AdoptOpenjDK - It's the defacto 'community' OpenJDK distro now (Amazon, Azul, GoDaddy, IBM, jClarity, Microsoft, Pivotal, Red Hat et al are collaborating there).  Let me know if you need any help connecting to our API:

https://api.adoptopenjdk.net

Cheers,
Martijn

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/71bc76d5-8f1c-4761-8654-0c4961d95216%40googlegroups.com.

[Baptiste Mathus]

Hey Martijn,

Thanks for chiming in. I already have commented there in the JIRA, but asking here since it seems at this stage better suited in a discussion place: do you have an opinion/idea about whether, and how long, it will be tolerated that certain IPs download the same JDK binaries from adoptopenjdk.net like dozens or hundreds of time a day? I mean: how is the bandwidth consumption handled on adoptopenjdk.net? Isn"t there a risk that some users be banned from downloading from there if they suck for instance +100GB, or much more, of bandwidth a day?

I'm asking because I've been arguing there and some other places that anyway this feature has always been problematic. And I tend to think it's cool for demos, but that normal usages shouldn't rely on downloading binaries from an external source forever, for a variety of reasons I've listed in the JIRA issue linked previously.

Thanks! :)

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAP7YuAT-guxrRa8J4GrpLfL_%2BUE4zZwCSa0GvEfUq49F2ficdQ%40mail.gmail.com.

[Slide]

How many people use the automatic installation, is there a way to track that? Would it kill someone's usage model to remove this feature? It seems to me to be fairly unsustainable.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CANWgJS5NhKXyvHaJinOkz4P9BpxPVC7eRi%2BzYaDbR_TFcVOfEQ%40mail.gmail.com.

[nicolas de loof]

I don't know if we have any metric for this purpose, but docker images seems to me a way better solution to cover the same need, and this "tool installer" feature is just a hack-ish legacy we should deprecate.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAPiUgVcA6VkkJxR-KStpaYn-S6SGO4h%2B_QfHa53BbV8XCbm8ug%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Nicolas De Loof

[Slide]

+1 on deprecation

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CANMVJz%3DrkCWQPnU58eiEdr%3DqpZmADAc7fZDTREXaxVUotm0jqg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Website: http://earl-of-code.com

[nicolas de loof]

I assume this would require a JEP ?

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAPiUgVcDW5%2BUi50SF-nnVXARhU-ZuoFMnY8NvCrV6%3DM6Fp-KnA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Nicolas De Loof

[Mykola Nikishov]

nicolas de loof <nicolas...@gmail.com>
writes:

> but docker images seems to me a way better solution to cover the same
> need, and this "tool installer" feature is just a hack-ish legacy we
> should deprecate.

Are you proposing to remove tool installer completely or is it about JDK
tool installer only?

If the former, to me this looks like maven vs freestyle project type
issue (when you have Maven project, of course) but moving in opposite
direction, from generic to concrete one. Tool installer is a generic
installer that supports installation of different tools. Docker images
support only a subset of these use-cases.

> Le mar. 26 févr. 2019 à 15:44, Slide
><slide...@gmail.com> a écrit :
>
>> How many people use the automatic installation, is there a way to track
>> that? Would it kill someone's usage model to remove this feature? It seems
>> to me to be fairly unsustainable.
>>
>> On Tue, Feb 26, 2019, 06:22 Baptiste Mathus <m...@batmat.net> wrote:
>>
>>> Hey Martijn,
>>>
>>> Thanks for chiming in. I already have commented there in the JIRA, but
>>> asking here since it seems at this stage better suited in a discussion
>>> place: do you have an opinion/idea about whether, and how long, it will be
>>> tolerated that certain IPs download the same JDK binaries from

>>> adoptopenjdk.net <https://api.adoptopenjdk.net/> like dozens or hundreds

>>> of time a day? I mean: how is the bandwidth consumption handled on
>>> adoptopenjdk.net? Isn"t there a risk that some users be banned from
>>> downloading from there if they suck for instance +100GB, or much more, of
>>> bandwidth a day?
>>>
>>> I'm asking because I've been arguing there and some other places that
>>> anyway this feature has always been problematic. And I tend to think it's
>>> cool for demos, but that normal usages shouldn't rely on downloading
>>> binaries from an external source forever, for a variety of reasons I've
>>> listed in the JIRA issue linked previously.

--
Mykola

Libre/Free Java Software Engineer
https://manandbytes.gitlab.io/

[Baptiste Mathus]

Yes and no. There's a way, but 1) it would require some coding adding a Telemetry like Daniel is doing for the Auto-Refresh https://github.com/jenkinsci/jenkins/pull/3894 and 2) this would only gather usages for newer core usages.

Or well, now I think about it, I think actually adding a Telemetry gathering directly in the to be deprecated plugin would allow running on older cores and get stats from instances more quickly.

Le mar. 26 févr. 2019 à 15:44, Slide <slide...@gmail.com> a écrit :

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAPiUgVcA6VkkJxR-KStpaYn-S6SGO4h%2B_QfHa53BbV8XCbm8ug%40mail.gmail.com.

[Baptiste Mathus]

It's not even about removing the JDK automated installer.

It is about removing the feature that will automatically propose you to download a JDK from external providers, like from oracle.com in the past, or from adoptopenjdk.net as it is being proposed. Because this is bad idea to constantly download the JDK from outside your company network for many reasons I already listed in https://issues.jenkins-ci.org/browse/JENKINS-54305?focusedCommentId=360351&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-360351

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/87h8cqff9u.fsf%40think.

[Sverre Moe]

In that case, you suggested a solution with a repository manager like Sonatype Nexus or Artifactory.

I like this proposal and we already are using Nexus in our organization.

Our Linux build servers have OpenJDK available to be installed through SUSE repositories.

It is mostly for our Windows and Mac builds we need either an older Oracle JDK or the newer OpenJDK. Up to now the JDK has been updated manually on these build servers.