[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [epp-dev] EPP 2020-12 RC2
|
Nitin,
Thanks!!
I've added this commentary to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=569111
It sounds like there are some things that would be good to be
able to debug, but without the hardware that doesn't seem
possible...
Perhaps if I can work remotely on the machine being used to build
the JRE... Let's see how many people download it and whether this
is worth my "free time" investment...
Yes, the installer adding the -vm option is expected. On Windows
the installer can know if you're using the default VM or not and
hence whether to add a -vm option or not, but that's harder to
determine on the other OSes and the request for the launcher to
record the PATH before the launcher mangles it hasn't moved
forward. Also on Windows, we can look in the registry to find
JVM installation, and Mac has a lookup mechanism as well. For
Linux it's not so clear how to find all the available JRE/JDK
choices (and no one has contributed something toward that
effort)...
Wanting a full JDK within the IDE for development is of course
orthogonal what's used to run the IDE, though of course the
default JRE configured by JDT is the one used to run the IDE, so
it doesn't really look so orthogonal. In any case, the installer
does have browse button that lets you choose a JDK located on your
machine...
Regards,
Ed
On 12.12.2020 00:04, Nitin Dahyabhai
wrote:
Ed,
I threw Fedora Workstation 33 onto a pi4 (well, a microSD
card) and tried it. While I got the same console message as
Liviu did about WebKit limitations, the installer opened and let
me pick the Enterprise Java option. The extracted contents of
the tarball didn't match the tarball's base name--I'm used to
those being the same. I have more disdain for the lack of
affordances and attention to UX in the default gnome shell than
when I last spent time with it, the better part of a decade ago.
There were frequent banner messages about "the installation
process is taking longer than usual", though, sometimes
mentioning it was while fetching or installing a particular
bundle, but at other times just listing the bundle name and no
indication of what action was taking longer than usual.
Installation of the Enterprise Java option failed for this
first attempt, however, with the subsequent
"installation log" display not accepting inputs, the desktop
UI telling me that SWT had become unresponsive, and while I
was typing this on another machine, closing itself out. The
second attempt from a reflash of the card/system succeeded,
and I'm not sure what the difference was between the two
attempts. A third attempt on that same system install, for the
JS package, also completed.
I don't have a lot of experience using the installer, but
it wrote a -vm line into the eclipse.ini file. As it
turns out, the Workstation install included a JRE, the path to
which is what was written into the eclipse.ini, but I needed
to install the full JDK package to properly develop Java and
debug a .jsp file locally on an ApacheTomcat instance. The
hard-coded -vm value wasn't updated automatically (not that I
expected that), but is hard coding the path the expected
behavior? I'd have thought it a choice between installing a
JustJ with a -vm switch into the .ini, or trusting the newly
installed Eclipse to find the same Java runtime that the
installer found at its own launch time.
So I guess that's a +1 for the installer itself on aarch64?