~~~ Jonah Graham Kichwa Coders www.kichwacoders.com
On Mon, 26 Sept 2022 at 07:18, Ed Merks <ed.me...@gmail.com> wrote: > Jonah, > > If I try your first set of steps, but *without *adding a JustJ JRE site, > I can hit the "Next" button on the "Updates Available" dialog as many times > as I like but I cannot proceed with the install. No explanation is given > why "Next" doesn't work, and nothing is in the error log to indicate what's > gone wrong. So such an IDE apparently can't be updated at all though for > no apparent reason. > I know that Mickael added a JRE processing step that is supposed to > determine if the current running JRE satisfies all the BREEs of all the IUs > to be installed, so no doubt this is kicking in, but now without explaining > to the user what's gone wrong. > This looks like a UI update bug, I had meant to mention it yesterday and I have now had time to file an issue: https://github.com/eclipse-equinox/p2/issues/146 > > Adding the JustJ JRE site indeed allows the install to proceed as you > observed; no doubt the presence the JustJ fake a.jre.org.eclipse.justj.* > IUs are not excluded like the fake a.jre.javase IUs (or the real JustJ ones > for that matter) during this JRE processing step, allowing the install to > proceed. If the processing step did exclude the JustJ fake ones no doubt a > real one would get installed like we saw before. And one can't arbitrarily > exclude the real ones too because that might be exactly what the user is > about to update making the overall update valid after a restart. > > Note that an unzipped CPP 2022-06 package's eclipse.ini contains this > twice: > > -Dosgi.requiredJavaVersion=11 > -Dosgi.requiredJavaVersion=11 > And the 2022-09 includes the =17 + =11 as different features are providing their own minimums. This is a very <https://bugs.eclipse.org/bugs/show_bug.cgi?id=367258> long <https://bugs.eclipse.org/bugs/show_bug.cgi?id=535551> standing <https://bugs.eclipse.org/bugs/show_bug.cgi?id=508091> issue <https://bugs.eclipse.org/bugs/show_bug.cgi?id=576113> (dups in eclipse.ini) but as the impact is greater of this one I think we need to try to work around the p2 limitation in EPP, perhaps even changing which source feature does this (CDT?) Raised Bug 580807 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=580807> > It seems we're stuck a bit between a rock and a hard place and even the > current behavior of older installations (refuse to update but don't explain > why) seems broken, though at least it never produces a somewhat broken > updated installation. That being said, in Jeff's case there was an > explicit failure to update, though the reason why is not clear to the > user... > > I'm also not comfortable hard-coding a specific update site in the JustJ > IUs because this takes control away from the consumer. E.g., if someone > installs JustJ Java 11 they'd generally not want an update site added that > would immediately allow updating to Java 17 because if they did want that, > they would not have installed Java 11 in the first place but rather Java > 17. So while it would be reasonable/okay to add > https://download.eclipse.org/justj/jres/XX/updates/release/latest/ when > installing Java XX to allow updates to newer versions of XX, that would not > solve the general EPP problem where eventually we'll want users to update > to some LTS version > 17 and EPP itself will determine exactly when that is > desired. Even adding a touchpoint to some EPP IU is questionable because > with the installer one can install an EPP package using a JRE local on the > machine, without using/installing a JustJ JRE. Also one can uninstall the > JustJ JRE. So I just don't see a 100% ideal solution. > > Maybe we should take the discussion offline to a bugzilla or issue? > I have raised Bug 580808 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=580808> - let's continue the conversation there. Jonah > Regards, > Ed > > On 26.09.2022 02:08, Jonah Graham wrote: > > > I also test installing Eierlegende Wollmilchsau for 2022-06 with a Java > 11 JDK installed on my machine (not a JustJ one) and updating it to 2022-09 > with https://download.eclipse.org/justj/jres/17/updates/release/latest > visible/available. > That too installed a.jre.org.eclipse.justj.openjdk.hotspot.jre.full. > > I did a similar test - but ended up with different(?) results, and more > importantly I ended up with a non-working IDE. > > This is what I did: > 1- System java is Java11 > 2- Install C/C++ using Oomph + system Java > 3- In newly launched IDE add > https://download.eclipse.org/justj/jres/17/updates/release/latest/ to > software sites > 4- Check for updates > 5- Everything seems to install fine, including things requiring Java 17 > (TM4E) > 6- Restart IDE, my error log now full of framework errors like this > (shortened for brevity, let me know if you need full log): > > org.osgi.framework.BundleException: Could not resolve module: > org.eclipse.tm4e.ui [761] > Unresolved requirement: Require-Capability: osgi.ee; filter:="(&(osgi.ee > =JavaSE)(version=17))" > > That is because I am still using Java 11, but Eclipse (with JustJ update > site) allowed me to install items requiring Java 17. > > I can get the same error as above like this: > 1- System java is Java11 > 2- unzip/untar eclipse-platform 4.25 and launch > 3- In Install New Software, choose "Wild web developer" > 4- Wizard will fail due to insufficient Java version > 5- Close wizard and add > https://download.eclipse.org/justj/jres/17/updates/release/latest/ to > software sites > 6- In Install New Software, choose "Wild web developer" > 7- Everything seems to install fine, including things requiring Java 17 > (TM4E) > 8- Restart IDE, my error log now full of framework errors like the above. > > I tried some other combinations of things, but overall simply adding the > URL seems unsatisfactory if the user isn't using JustJ already. If JustJ > was in use, it seems to do a perfectly fine job (on the one test I did) > > BTW - you may be asking how the IDE was even able to launch with the wrong > Java version, I think it is because the eclipse.ini gets updated to look > like this (shortened for brevity again): > > -vmargs > -Dosgi.requiredJavaVersion=17 > -Dosgi.requiredJavaVersion=11 > > So with the old osgi.requiredJavaVersion left in the file, the launching > steps don't warn the user as to what may be wrong. Ironically, if the > eclipse.ini update had worked, then the user would have an unlaunchable IDE > instead, until they updated to Java 17. > > Are you able to reproduce my above issues? If not, I can try again to make > sure I haven't done anything unexpected. > > Jonah > > > > ~~~ > Jonah Graham > Kichwa Coders > www.kichwacoders.com > > > On Sun, 25 Sept 2022 at 04:44, Ed Merks <ed.me...@gmail.com> wrote: > >> Jonah, >> >> I had some time to do additional testing and I believe the problem of >> unintentionally installing a real JustJ JRE is no longer a problem. See >> the details below the line. >> >> Therefore, I suspect the simplest solution is to compose >> https://download.eclipse.org/justj/jres/XX/updates/release/lates into >> https://download.eclipse.org/releases/latest where XX is the highest >> BREE of any IU in SimRel, currently 17. One advantage here is that we can >> change this site to impact existing installations even today, e.g., older >> installations that have JustJ JRE < 17 installed and are trying to update >> to the latest. It also means that anyone using JustJ JREs can choose the >> source of the updates themselves (perhaps a site within a corporate >> firewall or one of the JustJ sites) rather a specific site that I decide >> and hard-code, via touchpoints in the IUs, as the good one for everyone >> using JustJ. >> >> What do you think? >> >> _____________________________________________________ >> >> One thing that's changed since the bug reports, specifically the >> following about JustJ being installed simply because the IUs are visible: >> >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=569871 >> >> is that each site now contains its own "fake" a.jre IUs. E.g., >> >> >> https://download.eclipse.org/oomph/archive/reports-extra/justj-jres-17/download.eclipse.org/justj/jres/17/updates/release/latest/https___download.eclipse.org_justj_jres_17_updates_release_17.0.4.v20220903-1038/a.jre.org.eclipse.justj.openjdk.hotspot.jre.full_17.0.0.html >> >> which provides the same capabilities as the real JRE IU: >> >> >> https://download.eclipse.org/oomph/archive/reports-extra/justj-jres-17/download.eclipse.org/justj/jres/17/updates/release/latest/https___download.eclipse.org_justj_jres_17_updates_release_17.0.4.v20220903-1038/org.eclipse.justj.openjdk.hotspot.jre.full.win32.x86_64_17.0.4.v20220903-1038.html >> >> When I tried installing the Eierlegende Wollmilchsau for 2022-09, i.e., >> all IUs on the train, with >> https://download.eclipse.org/justj/jres/17/updates/release/latest as an >> available update site, the install log shows this: >> >> Installing a.jre.org.eclipse.justj.openjdk.hotspot.jre.full [17.0.0] >> >> So yes, a JustJ IU is installed, but it's the fake one just like the fake >> a.jre.javase IU that would otherwise be installed, so there are no >> associated artifacts and no -vm touchpoint is applied. >> >> I also test installing Eierlegende Wollmilchsau for 2022-06 with a Java >> 11 JDK installed on my machine (not a JustJ one) and updating it to 2022-09 >> with https://download.eclipse.org/justj/jres/17/updates/release/latest >> visible/available. That too installed >> a.jre.org.eclipse.justj.openjdk.hotspot.jre.full. >> >> Then finally I tested installing Eierlegende Wollmilchsau for 2022-06 >> with JustJ JRE 11 and the updating it with >> https://download.eclipse.org/justj/jres/17/updates/release/latest >> visible. As expected, it does install JustJ JRE 17 in that case, which is >> exactly the problem we are trying to solve. (Rather unexpected is that very >> few other things update, but that's a different problem of poor >> coordination of duplicates bundles). >> >> Note that this fake a.ajre JustJ IU was added so it can be used like this >> in a Tycho build to ensure that the build resolves the actual capabilities >> of the JRE that will be used by the built product: >> >> >> <executionEnvironment>org.eclipse.justj.openjdk.hotspot.jre.full_17-17</executionEnvironment> >> >> In any case, I believe there are no issues to come back. Either the >> JustJ fake IU satisfies the requirements or, if a real JustJ JRE IU is >> installed, the real JustJ JRE is updated if updates are available. >> >> Regards, >> Ed >> >> >> On 22.09.2022 15:39, Jonah Graham wrote: >> >> Hi folks, >> >> We do certainly need a solution to people who upgrade their IDE installs, >> but keep in mind there was pushback in the past of including JustJ in the >> SimRel*. It was related to p2 choosing to install JustJ when it wasn't >> needed (e.g. because already available on the user's machine) and that >> would cause unexpected results for the user. See >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=570899#c8 >> >> Perhaps if JustJ is included in an install, then JustJ should add its own >> p2 URLs to available sites - sort of how we do it for CDT: >> https://github.com/eclipse-cdt/cdt/blob/main/releng/org.eclipse.cdt-feature/p2.inf >> - that would mean only JustJ users have JustJ included in their available >> update sites. It won't resolve existing installs, but should help going >> forward when we upgrade past Java 17. >> >> I think installing an LTS JustJ should only upgrade to future LTS JustJs, >> so some of the discussions about what JustJ p2 URLs are still relevant. >> >> * I don't think it matters if it is in a composite or directly in the >> simrel repo, as long as it is visible in the simrel URL(s) then certainly >> these issues come back again. >> >> Jonah >> >> ~~~ >> Jonah Graham >> Kichwa Coders >> www.kichwacoders.com >> >> >> On Thu, 22 Sept 2022 at 03:04, Matthias Sohn <matthias.s...@gmail.com> >> wrote: >> >>> On Thu, Sep 22, 2022 at 8:17 AM Ed Merks <ed.me...@gmail.com> wrote: >>> >>>> Jeff, >>>> >>>> Given the regular release schedule of Adoptium/Temurin versions, often >>>> fixing security-related issues, baking a particular version into each >>>> release train repository, fixed to the particular version available at that >>>> time, doesn't seem like the best solution to this problem. Note too that >>>> it's highly unlikely the user was just updating 2022-06 but rather from >>>> something much older that was previously updated to 2022-06 because 2022-06 >>>> shipped with JustJ 17.0.x. >>>> >>>> Having an update site that is automatically added by EPP to each >>>> package and points to the desired current version would seem like a better >>>> solution. I vaguely recall having such discussions but obviously we didn't >>>> conclude that... >>>> >>>> There is also a question of which version should a JustJ update site >>>> specify? We could use this one: >>>> >>>> https://download.eclipse.org/justj/jres/ >>>> >>>> But that includes the 18.x release and soon the 19.x release. We >>>> probably don't want people updating to those. >>>> >>>> We could also compose this one: >>>> >>>> https://download.eclipse.org/justj/jres/17/updates/release/latest >>>> >>>> and update to some future LTS version eventually. >>>> >>>> Or maybe we should just compose the above into this site which I >>>> believe is already automatically added to all EPP packages: >>>> >>>> https://download.eclipse.org/releases/latest >>>> >>>> That would seem the simplest approach and would address the issue for >>>> existing installations already... >>>> >>> +1, this looks like the best approach >>> >>>> Regards, >>>> Ed >>>> >>>> On 21.09.2022 23:45, Jeff Johnston wrote: >>>> >>>> A user recently opened an issue against JDT UI because they were trying >>>> to update their 2022-06 Eclipse IDE for Java Developers and it fails >>>> because the current JustJ they had: 15.0.1 is not sufficient to update >>>> components which now require Java 17. >>>> >>>> While they can manually add the needed JustJ updates site would it not >>>> make sense to make a JustJ update available automatically for such >>>> end-users at least in the case where Eclipse increases minimum JVM >>>> requirements? >>>> >>>> -- Jeff J. >>>> >>>> _______________________________________________ >>>> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org >>>> To unsubscribe from this list, visit >>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >>>> >>>> _______________________________________________ >>>> cross-project-issues-dev mailing list >>>> cross-project-issues-dev@eclipse.org >>>> To unsubscribe from this list, visit >>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >>>> >>> _______________________________________________ >>> cross-project-issues-dev mailing list >>> cross-project-issues-dev@eclipse.org >>> To unsubscribe from this list, visit >>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >>> >> >> _______________________________________________ >> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >> >> _______________________________________________ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >> > > _______________________________________________ > cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev >
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
