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.
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:
And the 2022-09 includes the =17 + =11 as different features are providing their own minimums. This is a verylongstandingissue (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
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 - 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.
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):
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.
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.
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:
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.
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:
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?