On Mon, 6 Jan 2025 at 19:22, Michael Bien <mbie...@gmail.com> wrote: > IMO: -> good time to stop releasing NBI based windows "convenience > installers" since NBI is effectively unmaintained *
TL;DR dropping NBI means either concentrating on community installers or fixing the launcher ... We definitely need to work towards this, as NBI has effectively not been maintained in most of the time the project has been at ASF. I put time into NBPackage because I think NBI is also a fundamentally flawed approach that will just become more and more problematic. There are two things to consider. Firstly, we could, and actually in my opinion should, drop all the convenience installers and just provide the binary zip. Installers that rely on system JDKs are likely to become more problematic over time, given code signing, sandboxing, permissions and other factors. I think if people want to use a JDK of choice they should use the binary zip. That also means potentially looking to improve the range and availability of community installers, besides or instead of the ones I'm producing I hasten to add! That will involve continuing discussions somewhat independent of the project itself. The second thing, should we decide we do wish to continue delivering convenience installers that use a system JDK, is understanding some of the barriers to doing that with NBPackage for Windows right now. The NBI installer has code to find and write in the location of the JDK into netbeans.conf. While not impossible to achieve using the InnoSetup backend, or a future WiX backend, to NBPackage, I think it would be a bad idea. Writing the jdkhome into netbeans.conf, particularly in a system installed location, is a mistake. The launcher on Windows is no longer capable of finding a JDK itself. If the revised code from NBI was added into the launcher, that could allow both the installer and binary zip options to find a JDK without configuration. At the moment, the NBPackage Windows backend sets up --jdkhome in the desktop shortcuts it creates. This is quite useful, as you can even copy and have multiple shortcuts with different settings. It could also be possible to set the shortcut to point to --jdkhome "%JAVA_HOME%". You can try this with the current community installers, editing and overriding the existing internal link in the shortcut properties. However, it won't work unless you remove the final slash off the environment variable. Updating the launcher to not break with --jdkhome set to eg. C:\Program Files\Eclipse Adoptium\jdk-23.0.1.11-hotspot\ instead of C:\Program Files\Eclipse Adoptium\jdk-23.0.1.11-hotspot would be a bare minimum that could allow this to work pending other improvements. In doing that, we should also be able to provide some protection to check that JAVA_HOME is at least configured within the installer. Also updating the IDE launcher to support relative JDK home like the platform launcher does would be good for some other installer related things. Best wishes, Neil --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
