> Obviously a single, system installed JDK is less of a thing these days. I > don't think you can get an installer for Eclipse or IntelliJ that doesn't > bundle a runtime now.
I agree with this. Myself, I never "install" Java these days; I unzip it somewhere. > I don't think having a system installed IDE relying on any of these transient > user space things makes sense This is true--but perhaps it could be alleviated by having the installer install per-user rather than per-machine? This is what I did for my MSI installer, after a lot of research. It means that the IDE would end up in C:\Users\myusername\AppData\Local\Programs\NetBeans instead of in C:\Program Files\NetBeans The great thing about this is that no administrator access is needed to install. And if NetBeans is installed this way, then makes more sense to allow the user to browse to their own unzipped OpenJDK distro somewhere when they first run netbeans64.exe. If that folder later goes away, we can always prompt again. And inside the IDE, there's a lot more flexibility with respect to how to select JDK folders for actual builds (in Tools->Java Options). > There is an additional factor with macOS which might eventually be seen > elsewhere related to code signing, integrity and permissions. Never mind > admin permissions, you can't even change the netbeans.conf on the macOS > install without it being marked as broken. I'd propose the same approach as for the Windows installer; have a small native executable that prompts for the location of the JDK. Then remember it for subsequent runs. The single piece of information about where the JDK is can be stored in the user's home directory, e.g. "~/.netbeans". -- Eirik From: Neil C Smith <neilcsm...@apache.org> Reply-To: "dev@netbeans.apache.org" <dev@netbeans.apache.org> Date: Friday, March 21, 2025 at 11:59 AM To: "dev@netbeans.apache.org" <dev@netbeans.apache.org> Subject: Re: Re : Re: heads up: windows installer/uninstaller issues On Fri, 21 Mar 2025 at 15:03, Eirik Bakke <eba...@ultorg.com.inva<mailto:eba...@ultorg.com.inva>lid> wrote: 2) is unnecessary - we can already build a Windows installer using NBPackage - the only thing stopping us switching a long time ago is something like 1). OK, very good. Is the thing it generates an InnoSetup EXE that does not by itself require Java? Yes. Everything that NBPackage generates uses native tools and does not require Java at install time - InnoSetup exe, macOS pkg, Linux deb, rpm, or appimage. A JDK runtime is also optional in all the package types. All the other installers from ASF have been built with it for some time. The launcher issues on Windows are why we've stuck with NBI to date. We should fix them regardless because it would make the zip better. There is a way to use the InnoSetup installer now by customizing the shortcut to use netbeans --jdkhome "%JAVA_HOME%\" It's a bit clunky, and requires the extra backslash as I noted earlier on this thread because Windows decided that mixing path separators and escape characters makes sense! :-) > installers without a runtime have other issues Even if netbeans64.exe is updated to prompt for a JDK folder? Obviously a single, system installed JDK is less of a thing these days. I don't think you can get an installer for Eclipse or IntelliJ that doesn't bundle a runtime now. I have a whole bunch of JDKs on my machine, some installed, some downloaded manually, or by NetBeans, or by Gradle. I don't think having a system installed IDE relying on any of these transient user space things makes sense, even if I regularly test things using --jdkhome overrides. The default works out of the box, is a known entity, and is not affected by anything else. Nor does it affect anything else - the bundled JDK is an entirely private part of the installed IDE (or RCP app). There is an additional factor with macOS which might eventually be seen elsewhere related to code signing, integrity and permissions. Never mind admin permissions, you can't even change the netbeans.conf on the macOS install without it being marked as broken. NBPackage re-signs any JDK inside the app bundle with the same signature and hardened runtime permissions as the IDE. Not sure I understand... why would users build themselves an installer? It's an option. In particular if you're a company, college, etc. with a desire to bundle an alternative JDK to roll out. I used to regularly build myself a deb to install rather than the old Linux nbi! One of the things I'm working on with the community installer migration at the moment is a GitHub build workflow for all the packages. You could even fork that, change the JDK link, run it and have your own installer in about 10min (unsigned obv unless set up!). Best wishes, Neil --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org<mailto:dev-unsubscr...@netbeans.apache.org> For additional commands, e-mail: dev-h...@netbeans.apache.org<mailto:dev-h...@netbeans.apache.org> For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
