> 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 list cross-project-issues-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
