Bugzilla – Full Text Bug Listing
| Summary: | Should we post the Eclipse Installer that include a JRE on our download page by default? | ||
|---|---|---|---|
| Product: | Community | Reporter: | Christopher Guindon <chris.guindon> |
| Component: | Website | Assignee: | phoenix.ui <phoenix.ui-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | chr.j.schaefer, denis.roy, Ed.Merks, eric.poirier, karsten.thoms, Lars.Vogel, manderse, markus.tiede, mike.milinkovich, nobody, wayne.beaton |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X | ||
| See Also: |
https://git.eclipse.org/r/c/www.eclipse.org/eclipse.org-common/+/168766 https://git.eclipse.org/r/c/www.eclipse.org/downloads/+/168767 https://git.eclipse.org/c/www.eclipse.org/eclipse.org-common.git/commit/?id=66cde8b46a833d2eb9cdfa7828cef961122f803f |
||
| Whiteboard: | |||
| Bug Depends on: | 566451 | ||
| Bug Blocks: | 566452 | ||
| Attachments: | |||
|
Description
Christopher Guindon
I'm convinced that this is a good step. This prevents some failures to use Eclipse installer and packages on machines that don't have Java. This will increase the accessibility for many first time users and prevent failures with possibly wrong JRE versions. This is a no brainer: Yes! Yes, please! (In reply to Max Rydahl Andersen from comment #2) > This is a no brainer: Yes! +1 I don't recall the EPP project needing community approval to start distributing EPP packages with a JRE. Nor do they provide a package with a JRE as well as one without a JRE, unlike what I did with the installer to provide maximum flexibility for the consumers. But in the end, I don't understand the underlying thinking here that the installer's distributions require community approval while EPP's distributions do not. And worse still, instead of validating these distributions as part of m3, the process is delayed by this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=566451 (In reply to Ed Merks from comment #5) > I don't recall the EPP project needing community approval to start > distributing EPP packages with a JRE. Nor do they provide a package with a > JRE as well as one without a JRE, unlike what I did with the installer to > provide maximum flexibility for the consumers. > > But in the end, I don't understand the underlying thinking here that the > installer's distributions require community approval while EPP's > distributions do not. And worse still, instead of validating these > distributions as part of m3, the process is delayed by this: > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=566451 Ed, You are right that you don't need anyone's approval to start distributing EPP packages with a JRE. (Other than the Board approvals which have already happened.) But the download page itself has always been under the control of the Eclipse Foundation itself, and we are simply checking to make sure that folks like this new approach. Seems like everyone does like it, so hopefully we can declare victory here soon. The problem though is that RC1 is next Friday and if no one validates what's available now but rather first notice issues next Friday, the runway for fixing anything will be vanishingly small and increasingly risky. So while I understand that community input is good and fine, I don't understand how it makes sense to hold up making this available for m3. The whole purpose of these milestones is for early testing and for validation of functionality and quality. (In reply to Ed Merks from comment #7) > The problem though is that RC1 is next Friday and if no one validates what's > available now but rather first notice issues next Friday, the runway for > fixing anything will be vanishingly small and increasingly risky. > So while I understand that community input is good and fine, I don't > understand how it makes sense to hold up making this available for m3. The > whole purpose of these milestones is for early testing and for validation of > functionality and quality. I instructed Eric this morning to make sure the Eclipse Installer for 2020-09 M3 did not include the JRE. I feel like we should inform our users that they are NOW downloading the Eclipse Installer with a JRE. I created https://bugs.eclipse.org/bugs/show_bug.cgi?id=566452 to discuss these changes. If you all think we don't need to inform our users about this change, we can update the links. @Ed, if we do move forward with the Eclispe Installer with JRE, what are you expecting us to do with the files without the JRE? If we don't track them in the packaging site, their download won't be included in our download count. Is that a problem? I say we serve the JRE packages but put a huge notice on the page. We do want attention on this, this is huge. (In reply to Denis Roy from comment #9) > I say we serve the JRE packages but put a huge notice on the page. We do > want attention on this, this is huge. I will make the change! (In reply to Christopher Guindon from comment #10) > (In reply to Denis Roy from comment #9) > > I say we serve the JRE packages but put a huge notice on the page. We do > > want attention on this, this is huge. > > I will make the change! The changes are live! The Eclipse Installer with JRE is now the default download for Linux and Windows for Eclipse 2020-09 M3: https://www.eclipse.org/downloads/packages/release/2020-09/m3 I added an info block below the Eclipse Installer with the following text: The Eclipse Installer 2020-09 M3 now includes a JRE. This is a temporary solution that works for now but we still need to define the content change they we must do on https://www.eclipse.org/downloads/packages/ and https://www.eclipse.org/downloads/ before the September 16 release. > I added an info block below the Eclipse Installer with the following text:
> The Eclipse Installer 2020-09 M3 now includes a JRE.
Would it make sense to expand JRE, as in : The Eclipse Installer 2020-09 M3 now includes a Java Runtime Environment (JRE).
(In reply to Denis Roy from comment #12) > > I added an info block below the Eclipse Installer with the following text: > > The Eclipse Installer 2020-09 M3 now includes a JRE. > > Would it make sense to expand JRE, as in : The Eclipse Installer 2020-09 M3 > now includes a Java Runtime Environment (JRE). I know right now there is a block on the packaging page[1], but should there be a block on the Downloads[2] page itself as well? Maybe just a small line close to the download button that says that it includes a JRE? Or is this not necessary and just something on the packaging page is good enough? --- [1] - https://www.eclipse.org/downloads/packages/release/2020-09/m3 [2] - https://www.eclipse.org/downloads/ (In reply to Ed Merks from comment #7) > The whole purpose of these milestones is for early testing and for validation of > functionality and quality. Ed, where can folks report issues? https://twitter.com/apas_csc/status/1300475579205062658 "That's great. But by default selection Eclipse will be installed with -vm parameter pointing to temp directory of the installer: ...\AppData\Local\Temp\eoi9918.tmp\plugins\... Is this really how it should work?" Created attachment 283998 [details] Mockup with JRE emphasis I've attached a mockup that includes more emphasis on the JRE statement. Let me know if you require a design update to this page as well: https://www.eclipse.org/downloads/ The installer's menu opens links such as these: https://www.eclipse.org/setups/installer/question/ https://www.eclipse.org/setups/installer/problem/ The installer should create in installation with the -vm parameter specified in the choice dialog for that. I'll attach a picture. Of course the installer itself does indeed unpack itself to <user-home>\AppData\Local\Temp\eoi9918.tmp and does have a -vm option that points into the JRE in that folder's plugins folder. Created attachment 283999 [details]
The installer's JRE options does not include the installer's own JRE
I don't expect the installation itself to use or show the installer's own embedded JRE.
Note that Gunnar pointed out that JDK 11.0.2 has a potential security issue: https://www.eclipse.org/lists/technology-pmc/msg11968.html So I tested building the installer with JDK 14.0.2 instead. That works and for that version the Mac *.dmg can also be notarized. The disadvantage is that this JDK does not support unpack200 so the installer will download the *.jar not the *.pack.gz versions of the artifacts which are generally significantly larger. I will publish this version for RC1. I didn't see a response to this yet: https://bugs.eclipse.org/bugs/show_bug.cgi?id=566451#c5 I assume that's fine and * will generate the install-index.xml in this form and it will include an installer for mac. Hello Ed, I was asking on Twitter. I don't have a screenshot right now, but can try again tomorrow. I was offered a strange looking path as a default which turned out to be the temp directory and the two external options. This is on Windows 10 where my JAVA_HOME pointed to a JDK 8, an Oracle JRE 8 installed in the system and all other JDKs are installed in non-standard locations, so the installer probably wasn't able to offen a suitable local JDK/JRE. Yes, please include a screen shot. The code is designed to ensure that the installer's own embedded JRE is not available as an option and as you can see, in my case it's not available as an option... So I need to, at least in principle, figure out how to reproduce the problem that you've seen. Note that specifically this method should remove information about the JRE that's nested within the installer so that it's not available as a choice elsewhere in the framework: https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/plugins/org.eclipse.oomph.jreinfo/src/org/eclipse/oomph/jreinfo/JREManager.java#n391 Created attachment 284001 [details]
screenshot eclipse installer temp JRE
Created attachment 284002 [details]
screenshot eclipse installer temp JRE
Created attachment 284003 [details]
screenshot eclipse installer JVM selection temp JRE
Could it be that the code filtering the installer location confuses the actual home directory name C:\Users\christian.schaefer with the 8.3 name C:\Users\CHRIST-1.SCH? If you test with a short user profile name this probably won't happen to you. Thank you for reporting and for the necessary details!! Yes, it's clear that doing a string comparison in this case might well lead to a problem if both strings aren't using the ~ representation. I'll have to rework the code in question to do more proper comparison of files. I committed this fix: https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/commit/?id=26f77a49aaa35315430fa59153a8b0a7a107205a When this build finishes in the next hour (assuming nothing goes wrong): https://ci.eclipse.org/oomph/job/integration/4812/console Then this folder will contain new versions with the fix: https://download.eclipse.org/justj/?file=oomph/products/latest At that point the date of this will be newer that the current one: eclipse-inst-jre-restricted-win64.exe 102.19MB -rw-rw-r-- 2020-08-31 23:24:28 And this link will download it (from a mirror if available): https://www.eclipse.org/downloads/download.php?file=/oomph/products/latest/eclipse-inst-jre-restricted-win64.exe It would be super super helpful if you could test this version! I'm out most of the day, so I will have to check later on the status. I can confirm that with the fix the temp path is not offered anymore. Default is now the external 14.0.2 JustJ JRE. I like the overall installation experience and think it is even more important now that Eclipse will require Java 11. (In reply to Christie Witt from comment #15) > Created attachment 283998 [details] > Mockup with JRE emphasis > > I've attached a mockup that includes more emphasis on the JRE statement. > Let me know if you require a design update to this page as well: > https://www.eclipse.org/downloads/ +1 for this (In reply to Christian Schäfer from comment #28) > I can confirm that with the fix the temp path is not offered anymore. > Default is now the external 14.0.2 JustJ JRE. > I like the overall installation experience and think it is even more > important now that Eclipse will require Java 11. Christian, Thanks so very much yet again for your help! It's great that you reported this problem with exactly the details needed to fix it. Of course verifying that the problem is indeed fixed is a further bonus. Naturally we want everyone to have a good experience installing Eclipse 2020-09 with its the new requirement for Java 11; your assistance helps ensure that the experience will be a smooth one for as many people as possible. Created attachment 284016 [details] Mockup for update to https://www.eclipse.org/downloads/ (In reply to Christie Witt from comment #31) > Created attachment 284016 [details] > Mockup for update to https://www.eclipse.org/downloads/ +1 New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse.org-common/+/168766 New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/downloads/+/168767 Gerrit change https://git.eclipse.org/r/c/www.eclipse.org/eclipse.org-common/+/168766 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse.org-common.git/commit/?id=66cde8b46a833d2eb9cdfa7828cef961122f803f The website is ready for this release! Thank you Eric and Christie for working on this while I was on vacation :) It looks awesome! Some of the work is available here https://www.eclipse.org/downloads/packages/release/2020-09/rc1 The changes to the download page will be available tomorrow! |