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 <http://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 list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list,
visithttps://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 list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list,
visithttps://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
