|Re: [epp-dev] EPP 2020-12 RC2|
I've added this commentary to
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
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
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?
Back to the top