> Why would we have to preserve comments in an (almost certainly) non-existent > file? Note I mean <userdir>/etc/netbeans.conf and not the netbeans.conf in > the installation.
Oh, I assumed ~/etc/netbeans.conf was some existing, frequently used way to override the NetBeans configuration. If not, never mind. > Fine for Windows. Surprised that's working for you to pass notarization on > macOS. Actually, I was wrong--the script there is in fact signed with codesign. > The quicker fix might just be to look at making the launcher JAVA_HOME aware, > and show a better message about setting that? Yes, that's also an improvement! -- Eirik From: Neil C Smith <neilcsm...@apache.org> Reply-To: "dev@netbeans.apache.org" <dev@netbeans.apache.org> Date: Tuesday, March 25, 2025 at 1:27 PM To: "dev@netbeans.apache.org" <dev@netbeans.apache.org> Subject: Re: Re : Re: heads up: windows installer/uninstaller issues On Tue, 25 Mar 2025 at 16:50, Eirik Bakke <eba...@ultorg.com.inva<mailto:eba...@ultorg.com.inva>lid> wrote: > Well, the obvious place to store it would be the <userdir>/etc/netbeans.conf > although there's potentially a chicken and egg upgrade issue with doing that. That sounds fine, too. Though netbeans.conf is traditionally modified the user, and never automatically. If the launcher is going to modify a setting, it might be best to have a separate file for that so that we don't have to worry about preserving comments etc. (And so the user doesn't have to wonder if a change was their own or made automatically.) Why would we have to preserve comments in an (almost certainly) non-existent file? Note I mean <userdir>/etc/netbeans.conf and not the netbeans.conf in the installation. > But then we've also been making a move to get rid of native executables > rather than add more, as they're a pain for releasing. In my platform app I just treat the native executable as a pre-compiled asset that doesn't actually need to be re-built for each release. Exactly as we are doing, just they need to be voted on and release signed separately so they can be distributed for use in the build. I also intentionally do not sign it. (Rather, I sign the entire MSI installer on Windows and the entire application package on MacOS.) Fine for Windows. Surprised that's working for you to pass notarization on macOS. Yeah, my inclination would be to implement the same "browse for JDK on first start" enhancement in both the MacOS Swift launcher and the netbeans64.exe launcher on Windows. It's twice the work, but once it's done, it's done, and the launcher can be left alone again essentially forever. The fundamental difference being that the Swift launcher is not in the zip and the exe launcher is. The Swift launcher is also much simpler as it executes the existing shell script. As for being left alone again, we've had two updates to the Windows launcher in the last year or so. Although your proposal would potentially be a bigger change than either of those. The quicker fix might just be to look at making the launcher JAVA_HOME aware, and show a better message about setting that? There was a brief discussion on Slack about a Java-based launcher that could work either as a source file or compiled into a native image. I personally think that's an idea worth considering at least. It would improve our ability to enhance, maintain and adapt the launcher. 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
